netElastic vBNG Router

Configurations Guide
Table of Contents

Router Management​ 8
Start, Stop, and Restart the router​ 8
Router Configuration Primer​ 8
Set time, date and time zone​ 9
Change admin access password and using ssh key for confd access​ 9
Create additional confd (router) users​ 9
Create additional confd users with admin rights​ 9
Create additional confd users with limited rights​ 10
Create user group for users whose access is limited to certain modules​ 12
Remove confd users​ 13
Centralized Router Access Management​ 14
TACACS+ User Login Authentication​ 14
Radius User Login Authentication​ 15
Configure Inband Router Access​ 16
Inband Router Access without VRF​ 16
Inband Router Access under VRF​ 17
Alarms and Events​ 18
Router Security Configuration​ 18
Open Ports On the Router​ 18
Protect Router WAN or LAN ports against attacks.​ 19
Control Plane Protection​ 20
Control Plane Protection By Limiting Control Traffic​ 20
Control Plane Protection by Blocking Certain Traffic Flows​ 21
Syslog Configuration​ 21
SNMP Configuration​ 22
SNMP In-band and Out-band Access​ 23
SNMP Trap/Inform​ 23
Protect Router Against Attacks via SNMP In-band Connections​ 23
Load netElastic’s SNMP MIB Files​ 24
Test SNMP server by snmpwalk.​ 24
Zabbix Templates.​ 25
SNMP Security.​ 25
 SNMP troubleshooting.​ 26
Interface Management​ 27
Create/manage VLAN Interfaces​ 27
Create/manage eth-trunk/port channel/lacp Interface​ 29
Create Loopback Interfaces​ 30
Interface MTU, PPPoE MRU, TCP/IP MSS Settings​ 31
Setup Interface MTU​ 31
MTU, PPPoE MRU, and TCP/IP MSS adjustments​ 31
Test Link MTU With Ping Test​ 31
Assigning multiple IPs on an interface​ 32
QinQ and 802.1ad Settings​ 32
ARP Related Configurations​ 32
Configure ACL on an interface.​ 33
Configure Rate Limiter QoS on an interface​ 34
Configure Shaping on an interface​ 35
Shaping with a single rate limit on all traffic flows.​ 35
Shaping with group rate limit, but separate max rates for different flows.​ 36
Enable PPPoE/DHCP Client on Interfaces​ 37
Ingress Filtering for Multihomed Networks (RFC 3704)​ 38
Check interface stats​ 38
Check dropped packets stats​ 39
IPv4 Pool Configuration​ 39
Typical IPv4 Pool Configuration​ 40
IP Reservation and Static MAC/IP Binding​ 41
Configuring With Multiple Subnet Pools​ 42
IPoE With Multiple Subnet Pools.​ 42
Case I: Multiple Subnets separated by different VLANs​ 42
Case 2: Multiple Subnets sharing the same VLAN access​ 42
PPPoE With Multiple Subnet Pools​ 43
IP Pool Modification and Maintenance​ 44
Show IP Pool Status​ 44
DHCP Configuration​ 45
DHCP Configured as a Server​ 45
DHCP server as part of IPoE access​ 45
DHCP renew trigger user re-authentication with IPoE access​ 46
DHCP as standalone server for L2 connected clients​ 46
DHCP Broadcast Flag Override​ 47
DHCP as standalone server for clients through a relay agent​ 47
DHCP event logging with syslog.​ 49
DHCP Configured as a Relay Agent​ 50
DHCP Relay Agent Configuration.​ 50
 DHCP Relay Agent Supported Options​ 52
DHCP Relay Agent Troubleshooting.​ 53
Configure DHCP Policies​ 53
Send DHCP Client TR069 URL With Option 43​ 53
Send DHCP Client Static Routes With Option 121​ 54
Send Provision Server IP With Option 66​ 55
Send NTP Server IP With Option 42​ 55
Send With Option 125 and Conditionally Send Option 60​ 55
Check DHCP Status​ 56
Reset DHCP Leases​ 56
Subscriber Access Configuration​ 57
Understand Subscriber Access Call Flow​ 57
Understand Subscriber Access Authentication Credentials​ 58
Subscriber Access Credentials for PPPoE​ 58
Subscriber Access Credentials for IPoE​ 58
Understand Subscriber Access Domain​ 59
Access domain specification for PPPoE​ 59
Access domain specification for IPoE​ 60
Domain specification summary​ 61
Subscriber Access Configuration Flow - Component by Component​ 61
Access Configuration Flow Hierarchy​ 62
Authentication Template Configuration​ 63
Authorization Template Configuration​ 64
Accounting Template Configuration​ 66
Domain Template Configuration​ 66
PPPoX Template Template Configuration​ 67
IPoE Template Template Configuration​ 67
Enabling PPPoE and IPoE on Access Interfaces​ 67
Local Authentication with IPv4/v6 static IP, Mac-binding​ 68
Access Configuration by Access Types​ 68
PPPoE Access Configuration​ 68
IPoE Access Configuration​ 68
IPhost Configuration​ 69
Leased Line Configuration​ 73
L3 Mhox Access Configuration.​ 74
L3 Flow Access Configuration.​ 77
Access over VxLAN Configuration.​ 79
PPPoE over L2TP (LAC/LNS) Configuration.​ 82
VPWS Pseudowire Headend (PWHE) Configuration​ 82
Inter-subscriber Communications​ 82
Enable user routes​ 82
Setup ARP Proxy​ 83
 Block User Access Based on Uplink Availability.​ 83
Check User Access Status​ 84
User Access Troubleshooting​ 85
Check Online Fail Record Log​ 85
Check Abnormal Offline Record Log​ 85
Radius Integration and AAA​ 86
Radius Integration​ 86
Radius Global Configurations​ 86
Radius Authentication​ 86
Radius Authentication Group Definition​ 87
Authentication Template Definition​ 88
Check Authentication Request Status​ 90
Check Radius Access Status with radius-ping Test​ 90
Check Radius Access Status By Examining Radius Log​ 91
Check Access Status by Examining On-line Fail Records​ 91
Radius Authorization​ 91
Authorization Template​ 92
Check Radius Reply Attributes with Radius-ping​ 93
Commonly used Radius reply attributes.​ 93
Framed-IP-Address Attribute (public 8)​ 94
Framed-Route Attribute (public 22)​ 95
Framed-IPv6-Route (public 99)​ 96
User ACL​ 96
NetElastic-Qos-Profile-Name Attribute (private 31)​ 96
NetElastic-Domain-Name Attribute (private 138)​ 97
Radius DMCOA​ 97
Disconnect Subscribers​ 97
Switch Subscriber’s QoS Plan​ 98
Switch Subscriber’s Download and Upload Rates​ 98
User Reauthentication​ 98
Put Subscriber to Walled Garden​ 99
Radius Accounting​ 99
Enable Radius Accounting​ 99
More About Radius Accounting Templates​ 100
Check Radius Accounting Access with radius-ping Test​ 102
Flow Based Accounting​ 102
Example 1 - Separate Usage Accounting for Different Flows​ 103
Example 2 - Total Usage Accounting Excluding IPTV​ 104
Check Flow Based Accounting Results​ 105
Translate Other Vendor’s VSAs​ 106
Radius Troubleshooting​ 107
Access Control with ACL​ 109
 User ACL to whitelist traffic from known IPs and apply to the interface.​ 109
Use ACL to blacklist traffic to/from known bad IPs and apply to an interface​ 109
Use ACL to block traffic to/from certain IPs and apply to subscribers​ 110
Domain-based ACL​ 111
QoS Rate Control and Queues​ 111
QoS Profile Based Rate Limiting​ 113
QoS profile with multiple rates for different flows.​ 113
QoS with priority given to speed test.​ 116
QoS - Priority Based Queues​ 117
Applying QoS profiles to subscribers.​ 120
Allow/deny users when users QoS profiles do not exist​ 120
Subcar Rate Limiting QoS​ 121
Subcar v.s QoS Profile Rate Limiting QoS​ 123
Time Based QoS​ 123
DNS Relay Agent Configuration​ 124
DNS Relay Server Configuration​ 124
DNS Relay Server Validation.​ 126
DNS Relay Configuration for Domain-based ACL​ 126
IPv4/IPv6 Dual Stack, IPv6 PD (Prefix Delegation)​ 127
Different Modes of IPv6 Address Allocations Supported​ 127
IPv4/IPv6 Dual Stack Authentication Process​ 128
IPv6 Stack Configurations​ 129
IPv4/IPv6 Dual Stack Troubleshooting​ 136
IGMP/PIM Configurations​ 137
IGMP Configuration​ 137
IGMP Troubleshooting​ 139
Router Configurations​ 139
General Router Debug Tips​ 139
Static Routes​ 140
OSPF​ 141
OSPF Example - V4​ 141
OSPF Example - V6​ 142
OSPF Route Filtering - Example 1​ 142
OSPF Route Filtering - Example 2​ 143
OSPF Route Advertise Tips​ 144
OSPF Troubleshooting​ 144
BGP​ 145
Sample BGP Configuration Overview​ 145
Advertise routes to neighbors​ 147
Add Route-map Filter to control BGP advertise/receive lists​ 150
Example 1: Use route filter on incoming and outgoing routes​ 151
Example 2: Use access list to filter incoming routes​ 153
 Example 3: Use route map filter to only accept the default route​ 153
Example 4: Use prefix-list route map to filter outgoing routes​ 154
Example 5: Use aspath ACL to filter routes by AS numbers​ 155
Configure BGP Router as Route Reflector​ 156
Configure Both V4 and V6 Neighbours​ 156
Configuring BGP under VRF​ 157
Using BGP Confederation​ 159
Settings for Large BGP Routing Tables.​ 159
BGP Troubleshooting​ 160
ISIS​ 161
ISIS Configuration​ 161
ISIS troubleshooting​ 162
Use tracker to detect link state change and update routing table​ 162
Update Static routes with ping detect tracker​ 162
Update BGP routes with ping detect tracker​ 163
Update BGP routes with BFD tracker​ 164
Policy Based Routing (PBR).​ 165
VRF Configuration​ 167
Use VRF to create separate access and routing entities.​ 167
Use VRF to isolate radius control traffic.​ 169
Http redirect, walled garden, and portal access​ 169
Static HTTP Redirect​ 170
Always Redirect Upon Authentication​ 170
Conditional Redirect By Radius Authentication Instruction​ 172
Conditional Redirect Upon Authentication Failure​ 172
Dynamic HTTP Redirect/Walled Garden by Radius DMCOA​ 173
Prepaid Online Access Http Redirect​ 174
Statically Configure Usage Quota and Redirect Behavior.​ 175
Dynamically Set Usage Quota and Redirect URL​ 176
Portal Access Control.​ 176
IP Flow Information Export (IPFIX)​ 176
IPFIX Configuration​ 176
IPFIX Troubleshooting​ 179
Check the IPFIX flow tables in the DP​ 179
Common IPFIX Troubleshooting Tips​ 179
Lawful Intercept (LI) Configuration​ 180
LI Server Configuration.​ 180
LI Users Configuration.​ 181
Check LI Running Status.​ 181
Router Management

Start, Stop, and Restart the router

When the router boots up, all router related processes should automatically start and run. To check the
router running status, type “flexbng”. All processes of the router will be listed with their running status
(RUNNING or STOPPED). When the router is running normally, all processes of the router should be in
RUNNING states.

●​ To stop the router, type “flexbng -S”. This will stop the router
●​ To start or restart the router, type “flexbng -s”. This will star/restart the router. After the router
is started, give it some time (10-30 seconds) and type “flexbng” to check the running stats of all
the router processes. When all processes are in RUNNING status, the router restart process is
completed.

NOTE 1: You may be asked to set/enter a password when running commands “flexbng -S” or
“flexbng -S”. This password is saved in clear text and it is not meant for strong security, but to
prevent you from accidentally restarting the router. If you forget the saved password, you can recall it
by typing “cat /usr/local/certus/version/.[Link]”. If the command returns nothing ,it
means the password has not been set. ​

If you want to reset the password, follow these steps.

1.​ Type “chattr -i /usr/local/certus/version/.[Link]” ​
The password file is immutable. This will remove the immutable attribute of the password file. You
can usse the command “lsattr /usr/local/certus/version/.[Link]” to validate
that the “i” attribute has been removed.
2.​ Type “rm -i /usr/local/certus/version/.[Link]” to remove the password file.
3.​ Type “flexbng -s” to reset the password.
​
NOTE 2: Restarting the router in the above mentioned manner only restarts the router’s running
processes and won’t trigger the DPDK binding process for the NIC ports. DPDK binding for the ports
are part of the boot process. If you have made changes at the port level, you do need to reboot the host
for them to take effect.

Router Configuration Primer

Before we begin configuring the router, please spend a few minutes going through the router
configuration primer to familiarize yourself with how to configure a netElstic vRouter.
Set time, date and time zone
The system time, date, and time zone can be set either on the router or on the host Linux system. Please
refer to the instructions at this link

Change admin access password and using ssh key for confd access
Confd (router shell) comes with the default user “admin” with default password “admin”.
●​ To change admin password, please follow this guide
●​ To set up confd access with ssh key, please follow this guide.

Create additional confd (router) users

Create additional confd users with admin rights

To create additional confd users with admin rights, follow these steps.
1.​ Login to the router as admin (e.g. ssh admin@0 -p 2024 from the host). You won’t be able
to add users if you get to the router by the command “confd_cli”
2.​ To list current configured users type “show running-config aaa authentication
user”. The information for the current admin users will be listed as shown below
domain# show running-config aaa
aaa authentication ssh-key-mode none
aaa authentication users user admin
uid ​ 9000
gid ​ 100
password $1$LTbmqaem$J9KOGxoB8N6pWvqbH307f0
ssh_keydir /var/confd/homes/admin/.ssh
homedir​ /var/confd/homes/admin
exit
Take a note of the uid, gid, ssh_keydir, and homedir settings. You will use them for creating the
new admin user later.
3.​ After login into the router as admin. Type “config” to get into configuration mode.
4.​ Type “aaa authentication users user [userName]” to initiate user creation dialog.
You will be prompted to enter uid (user ID), gid (group id), password, and ssh_keydir (ssh key
directory), and homedir (home directory). You can use the same information shown in step 2.
Type exit to exit back to the root configuration level.
domain(config)# aaa authentication users user user2-admin
Value for 'uid' (<int>): 9000
Value for 'gid' (<int>): 100
Value for 'password' (<hash digest string>): **********
Value for 'ssh_keydir' (<string>): /var/confd/homes/admin/.ssh
Value for 'homedir' (<string>): /var/confd/homes/admin
domain(config-aaa-authentication-users-user-user2-admin)# exit
domain(config)#
 5.​ Add the new user to the admin group so the new user will have admin rights as shown below.
Commit the changes and exit out of the configuration mode
domain(config)# nacm groups group admin user-name user2-admin
domain(config-nacm-groups-group-admin)# commit
Commit complete.
domain(config-nacm-groups-group-admin)# end
domain#
6.​ Log in with the new user and confirm the user does have admin rights.
[root@domain ~]# ssh user2-admin@0 -p 2024
user2-admin@0's password:
user2-admin connected from [Link] using ssh on domain
domain# show run aaa
aaa authentication ssh-key-mode none
aaa authentication users user admin
uid ​ 9000
gid ​ 100
password $1$LTbmqaem$J9KOGxoB8N6pWvqbH307f0
ssh_keydir /var/confd/homes/admin/.ssh
homedir​ /var/confd/homes/admin
exit
aaa authentication users user user2-admin
uid ​ 9000
gid ​ 100
password $1$JwTohfcZ$Wl.EZN1P7q.pKyHvoqalT0
ssh_keydir /var/confd/homes/admin/.ssh
homedir​ " /var/confd/homes/admin"
exit

Create additional confd users with limited rights

The users created by following the above steps have the same access rights as the default admin
user. To create an additional user with limited access privileges, follow the following example where
we will create a user called “operator” with password “123456”. User “operator” shall only have read
access to confd meaning the user “operator” can only see the configuration with commands like
“show run” and execute router operation commands such as “show nat status, ping”, etc.
1.​ Login to confd as admin. Or enter confd with “confd_cli -noaaa” so you have administrator
rights to create users and manage their access privileges.
2.​ Type config to enter root configuration mode.
3.​ Create a user called operator with password 123456, group id and user id being 1000 and
home directory /var/confd/homes/operator by issuing the following command. ​
“aaa authentication users user operator password 123456 gid 1000 uid
1000 homedir /var/confd/homes/operator”​
The above command will trigger the user creation dialog and you will be asked to enter “Value
for 'ssh_keydir'”, type “/var/confd/homes/operator/.ssh” as the ssh_keydir string.
4.​ Type “show full” to examine the user “operator” settings, then type “commit” and “exit” to
exit back to the root config level.
 5.​ Enable user privilege management with the command:​
“nacm enable-nacm true”
6.​ Disable the default write privileges with the command:​
“nacm write-default deny”
7.​ Create a user group called “oper” and add user operator to the group by the command:​
“nacm groups group oper user-name operator”
8.​ Type “show full” to examine the user list in the user group “oper” to make sure the user
operator is in the list. Then type “commit” and “exit” to exit back to the root config level.
9.​ Next create a rule group called “read-only” and tie it to the user group “oper”. Also create a
rule called “allow-read” under the “read-only” rule group. The rule “allow-read”
controls the access operation to be read only, applied to all modules (*), and the action is “permit”.
All these is done with one line command:​
nacm rule-list read-only group oper rule allow-read access-operations
read module-name * action permit
10.​ Type “show full” to examine the rule group “read-only” and rule “allow-read” settings,
then type “commit” and “end” to exit configuration mode.
11.​ Exit back to Linux and you can try to connect with the newly created user by ssh operator@IP
-p 2024. You should be able to login with password “123456” and you should not be able to
configure anything once you login. ​

The following screen capture shows the whole configuration process with the user inputs highlighted
in green

netelastic(config)# aaa authentication users user operator password 123456 gid

1000 uid 1000 homedir /var/confd/homes/operator
Value for 'ssh_keydir' (<string>): /var/confd/homes/operator/.ssh
netelastic(config-aaa-authentication-users-user-operator)# show full
aaa authentication users user operator
uid ​ 1000
gid ​ 1000
password $1$vEv0.5Tj$[Link]/1
ssh_keydir /var/confd/homes/operator/.ssh
homedir​ /var/confd/homes/operator
exit
netelastic(config-aaa-authentication-users-user-operator)# commit
Commit complete.
netelastic(config-aaa-authentication-users-user-operator)# exit
netelastic(config)# nacm enable-nacm true
netelastic(config)# nacm write-default deny
netelastic(config)# nacm groups group oper user-name operator
netelastic(config-nacm-groups-group-oper)# show full
nacm groups group oper
user-name [ oper operator public reader ]
exit
netelastic(config-nacm-groups-group-oper)# commit
Commit complete.
netelastic(config-nacm-groups-group-oper)# exit
netelastic(config)# nacm rule-list read-only group oper rule allow-read
access-operations read module-name * action permit
netelastic(config-nacm-rule-list-read-only-rule-allow-read)# show full
nacm rule-list read-only
rule allow-read
 module-name ​ *
access-operations read
action ​ permit
exit
exit
netelastic(config-nacm-rule-list-read-only-rule-allow-read)# commit
% No modifications to commit.
netelastic(config-nacm-rule-list-read-only-rule-allow-read)# end
netelastic#

Create user group for users whose access is limited to certain modules
To create a user group for users who access right is limited to certain modules, follow these steps:
1.​ login to the router as admin
2.​ create a NACM limited access group and add the users who should be placed under this group
into this group.
3.​ Define a NACM rule list where the module access rules are defined and bind the rule to the
NACM access group defined in step 2.

Here is a configuration example for a user group whose members only have access to checking
certain modules states and show running configurations for certain modules. You can customize
access of your desired modules based on the examples provided.

! define a NACM access group

nacm groups group restricted-operator
user-name [ natUser1 ] ! users that are subject to this rule grp
user-name [ natUser2 ] ! users can be setup in TACPLUS server
exit

! define a NACM rule list and bind it to the rule group defined
nacm rule-list nat-operator
group [ restricted-operato ] ! bind the rule-list to the rule group
! allow reading smgr session info
rule allow-smgr
module-name netelastic-flexbng-smgr
path *
access-operations read
action permit
exit
! allow reading pppoe session info
rule allow-pppoe
module-name netelastic-flexbng-pppoe
path *
access-operations read
action permit
exit
! allow reading acl configuration
rule allow-acl
module-name netelastic-flexbng-acl
path *
 access-operations read
action permit
exit
rule allow-nat ! allow reading nat config
module-name netelastic-flexbng-nat
path *
access-operations read
action permit
exit
rule allow-hdp-nat ! allow reading nat status
module-name netelastic-flexbng-hdp-nat
path *
access-operations read
action permit
exit
rule allow-ippool ! allow reading ipool info
module-name netelastic-flexbng-ippool
path *
access-operations read
action permit
exit
! allow clearing online-fail-record
rule allow-clear-online-fail-record
module-name netelastic-flexbng-smgr
rpc-name clear-vbras-online-fail-record
access-operations exec
action permit
exit
! allow clearing pppoe sessions
rule allow-clear-pppoe-session
module-name netelastic-flexbng-pppoe
rpc-name clear-pppoe-session
access-operations exec
action permit
exit
rule others ! deny all other access
action deny
exit
! add a rule to block commands like “system clear config”,
! “system reboot”, and “system service reboot”, etc
cmdrule block-sys
command system
access-operations *
action deny
exit
exit

Remove confd users

To remove confd users, follow the below steps:
1.​ login to the router as admin
 2.​ get into configuration mode by “config”
3.​ remove the user by “no aaa authentication users user [userToBeRemoved]”
4.​ commit the change and exit.

The above procedure is illustrated in the following example

[root@domain ~]# ssh admin@0 -p 2024
admin@0's password:
admin connected from [Link] using ssh on domain
domain(config)# no aaa authentication users user user2-admin
domain(config)# commit
Commit complete.
domain(config)# exit
domain#

Centralized Router Access Management

netElastic routers support centralized user authentication services for accessing the router with either
TACACS+ or RADIUS

TACACS+ User Login Authentication

To enable TACACS configuration, you have to configure the following:
●​ Under system -> login , set authentication-order to use tacplus first
●​ Set tacplus out-band disabled if tacplus servers are connected via inband (router)
interfaces. Otherwise, set tacplus out-band enabled if acplus servers are connected
via out-band (host) interfaces.
●​ Under tacplus group default, add tacplus authentication and accounting servers.​

Here is a sample configuration for using tacsplus. Please be aware that the tacsplus group name
has to be "default".

domain# show running-config system #system level configuration

system hostname domain
system login authentication-order tacplus local
domain# show running-config tacplus # TACPLUS configuration
tacplus out-band disabled
tacplus accounting enabled
tacplus group default
source-ip [Link]
timer response-timeout 5
timer quiet 5
authentication server 1 ipv4-address [Link] port 49 shared-key test
authorization server 1 ipv4-address [Link] port 49 shared-key test
accounting server 1 ipv4-address [Link] port 49 shared-key test
exit
 You can use the command “show tacplus authentication/authorization/accounting”
to display tacplus server status. If TACACS is not behaving as expected, you can troubleshoot by
examining the TACACS log file which is located at
/var/log/certus/go/tacplus/[Link]

NOTE:
●​ TACACS supports both inband and out-band connections. When using inband connections,
make sure to set tacplus out-band to disable
●​ When using TACACS, the password can not contain white spaces.
●​ The type of security for login that the router expects is PAP (Password Authentication
Protocol). PAP needs to be set as the auth option on the TACACS server for the TACACS to
work.
●​ The router currently does not support TACACS accounting.

Radius User Login Authentication

To configure system login with radius authentication, follow these steps:
●​ configure an radius server group
●​ configure radius confd authentication and bind the authentication to the radius server group
defined in the above step.
●​ configure the system login to use radius authentication.
This following shows a configuration example:
! configure a radius authentication group
radius authentication group radius_authen
server-type ipv4-server
timeout 3
retry-times 3
nas-ip-address [Link]
dead-time 5
dead-count 10
class-as-car disable
filter-id-type user-acl
algorithm-auth master
server 1 ipv4-address [Link] port 1812 key testing123
exit

! configure radius confd authentication and bind the

! above defined radius authentication group
radius confd-auth-group radius_authen

! configure the system login to use radius authentication

system login authentication-order local radius

NOTE: You can configure to use radius to authenticate and then fall back to local by configuring the
syslog login authentication order as “system login authentication-order radius local”
Configure Inband Router Access

Inband Router Access without VRF

You can access the router control (even the host) through inband connections. Inband connections
means connections through router interfaces as opposed to management (outband) interfaces. The
communication between inband connections and the host processes is made possible by a process
called flexlink. To show the forwarding rules of flexlink, use the command “show flexlink”

●​ To enable ssh inband connection to the router’s confd command line, configure the following (port
2024 is used in the example).
ssh-server in-band enable true
ssh-server in-band port 2024
With this configured, you can access router confd cmd by ssh admin@ip -p 2024

●​ To enable ssh inband connection to the router’s netconf machine interface, configure the following
(port 2022 is used in the example).
netconf-server in-band enable true
netconf-server in-band port 2022
With this configured, you can configure your netconf compatible application such as the BNG
Manager to access router netconf by ssh admin@ip -p 2022

●​ To enable ssh inband connection to the router’s host Linux system, configure the following (port
2222 is used in the example).
host-server in-band enable true
host-server in-band port 2222
​ With this configured, you can access router’s host Linux by ssh root@ip -p 2222

With all these inband access methods, if your ssh client has ssh-dss disabled by default, you might get
the error message “no matching host key type found”. In that case you can add the option
-oHostKeyAlgorithms=+ssh-dss to the SSH command such as ​
“ssh -oHostKeyAlgorithms=+ssh-dss admin@[Link] -p 2024”

You can also optionally bind the interface and inband access control list to control from which interface
and what IP address the inband access will be allowed. Here is an example of netconf-server inband
access configuration with interface and inband acl controls. In this example, the inband netconf control is
only allowed from interface 10gei-1/1/1 and from IPs within the subnet of [Link]/22. Please note that
the inband access control access list is defined differently from the general purpose access control list.
! define inband access control list
flexlink access-list
rule flexlink_access_list
global deny all
 ip-prefix [Link]/22 permit
exit
exit

! configure netconf inband access

netconf-server in-band enable true
netconf-server in-band port 2022
netconf-server in-band bind interface 10gei-1/1/1
netconf-server in-band bind acl flexlink_access_list

Inband Router Access under VRF

You can put inband access under its own VRF to separate the management access from the forwarding
path by VRF. Here is a configuration example.

! create management vrf

l3vpn vrf management
rd 213094:10
exit

! bind flexblink to vrf

flexlink vrf management

flexlink access-list
rule mgmt_access
global deny all
ip-prefix [Link]/8 permit
exit
exit

netconf-server in-band enable true

netconf-server in-band port 2022
netconf-server in-band bind interface 100gei-1/1/1.200
netconf-server in-band bind acl mgmt_access
ssh-server in-band enable true
ssh-server in-band port 22
ssh-server in-band bind interface 100gei-1/1/1.200
host-server in-band enable true
host-server in-band port 2222
host-server in-band bind interface 100gei-1/1/1.200
host-server in-band bind acl mgmt_access

interface 100gei-1/1/1.200
description "Management Network"
bind vrf management
ipv4 address [Link] 29
dot1q 200
exit

router static
 ip route vrf management [Link] [Link] nexthop [Link]
exit

Alarms and Events

The router maintains an alarm tracking system to which important events from different modules such as
ippool, radius, smgr, etc will be written. Event records and history can be viewed with the commands by
“show alarm current” and “show alarm history”.

The event severity levels in the alarm management system are:

Value Severity Keyword Description

0 Emergency emerg System is unusable

1 Alert alert Action must be taken immediately
2 Critical crit Critical conditions
3 Error err Error conditions
4 Warning warning Warning conditions
5 Notice notice Normal but significant conditions
6 Informational info Informational messages
7 Debug debug Debug-level messages

Router Security Configuration

All the physical ports on the physical device on which the router runs fall into two categories:
●​ Management ports​
These are the ports you didn’t choose as router ports during installation. These ports are only
available in the host Linux kernel and thus can be used to access the router’s host CentOS. To
protect the router’s host OS against malicious attack, please follow the best common Linux
security practices, some of which are described in our installation guide.
●​ Router ports​
These are the ports you choose as router ports during installation. After the router runs, these
ports will be taken by the router and won’t be available in the Linux kernel. These ports do not
have any relevance in terms of host Linux security concerns. The following notes deal with
common best practices to protect the router against malicious traffic coming from these router
ports.

Open Ports On the Router

The router usually has the following ports open on the router forwarding ports.
●​ 443: This https port is open by default for portal https redirect purpose
 ●​ 179: The BGP port is open whenever the BGP instance is configured
You can choose to block these ports—along with specific IP addresses and interfaces you want to
protect—using the control plane blacklist as described below.

Protect Router WAN or LAN ports against attacks.

You can use ACL to protect the router against attacks or filter out unwanted traffic. The configuration has
the following steps.
●​ Define ACL rules to filter out unwanted traffic. The ACL rules allow you to filter by IP address,
port number, protocol etc.
●​ Apply the defined ACL rules to the relevant interfaces.

Here is an example configure where we

●​ Block all DNS lookup requests on the WAN port 10gei-1/1/1. We achieve this by blocking
destination port 53 for all TCP and UDP packets.
●​ Block all ICMP requests on the WAN port 10gei-1/1/1 except from a known IP 192,168,1,12/32.
We achieve this by blocking protocol 1 except from the known IP.
●​ Block all incoming https connections towards the WAN port.
●​ Block TCP and UDP ports 135-139 and 444-445 on the LAN port 10gei-1/1/0

! define ACL to block certain flows on the WAN interfaces

access-list WAN-blockList
rule 10 deny udp source any gt 0 destination any eq 53
rule 20 deny tcp source any gt 0 destination any eq 53
rule 50 permit specify 1 source [Link]/32 destination any
rule 60 deny tcp source any gt 0 destination [Link]/32 eq 443
rule 70 deny specify 1 source any destination any
rule 100 permit ip source any destination any
exit

! define ACL to block certain flows on the LAN interfaces

access-list LAN-blockList
rule 10 deny udp source any gt 0 destination any range 135 139
rule 20 deny tcp source any gt 0 destination any range 135 139
rule 30 deny udp source any gt 0 destination any range 444 445
rule 40 deny tcp source any gt 0 destination any range 444 445
rule 100 permit ip source any destination any
exit

! apply ACL to the WAN interface

interface 10gei-1/1/1
bind acl in ipv4 WAN-blockList
ipv4 address [Link] 32
exit

! apply ACL to the LAN interface

interface 10gei-1/1/0
bind acl in ipv4 LAN-blockList
exit
Control Plane Protection
All control traffic received by the dataplane will be forwarded to the control plane for processing. In the
case of a malicious attack, the volume of attack traffic could overwhelm the control plane and tie up
computing resources on the CP for normal control traffic processing. The current internal channel
between CP and DP has a max capacity of 130Mbs bidirectional which corresponds to about 12K-15K
pps.

To display the internal channel traffic rates from the dataplane to the control plane, follow these steps:
1.​ Login to the data plane by “telnet 0 5002”
2.​ Type “show int internal speed” to display the rx (cp->dp)/tx (dp->cp) rates.

The rx/tx rates are in the unit of packets per second. You want to limit the steady amount of traffic
between DP and CP to something less than 30M pps. It is expected that the internal traffic could
momentarily go beyond 30M pps when users are all trying to get online at the same time. However,
normal steady state control traffic for 32K subscribers should be less than 30M pps. If the steady state
internal traffic rate is high, you could try to reduce it by the following:
1.​ Reduce the radius accounting update rate.
2.​ Reduce dhcp renewal interval.
3.​ User outbound connection for snmp and nat logging.

Control Plane Protection By Limiting Control Traffic

In the event of an attack to the control plane, you will see the internal traffic rate goes high. You can
protect the control plane against malicious attack traffic by limiting the amount of traffic going from the
dataplane to the control plane. You can set a bandwidth limit for each of the traffic categories as listed
in the following sample control plane security bandwidth protection configuration. Note it is important to
set “cp-car rule default-bandwidth” to the smallest possible value 1024 to limit unclassified attack
traffic from reaching to the control plane.

security
sync-flood bandwidth 30000
cpu-defend-policy
white-list mode disable
black-list mode disable
cp-car mode enable
cp-car rule ospf-bandwidth 30000
cp-car rule bgp-bandwidth 30000
cp-car rule rip-bandwidth 20000
cp-car rule dhcp-c2s-bandwidth 20000
cp-car rule dhcp-s2c-bandwidth 20000
cp-car rule icmp-bandwidth 20000
cp-car rule igmp-bandwidth 20000
cp-car rule ldp-bandwidth 30000
cp-car rule pim-bandwidth 20000
cp-car rule l2tp-bandwidth 20000
 cp-car rule multicast-bandwidth 30000
cp-car rule radius-bandwidth 20000
cp-car rule portal-bandwidth 20000
cp-car rule ipsec-bandwidth 20000
cp-car rule isis-bandwidth 30000
cp-car rule arp-bandwidth 20000
cp-car rule pppoe-disc-bandwidth 20000
cp-car rule pppoe-sess-req-bandwidth 20000
cp-car rule pppoe-sess-reply-bandwidth 20000
cp-car rule pppoe-sess-other-bandwidth 20000
cp-car rule default-bandwidth 1024
exit
exit

Control Plane Protection by Blocking Certain Traffic Flows

You can further protect the control plane by allowing traffic only from trusted sources and blocking
unwanted flows using the control-plane whitelist and blacklist features. This feature is available in
versions after B4P30 or B5P7.

Here is an example of blocking BGP and HTTPS traffic destined for the user-side VGI interface IP:
! define an access list to specify the flows for bgp and https to the
! user side vgi interface IP.
access-list Block-BGP
rule 10 permit tcp source any gt 0 destination [Link]/32 eq bgp
rule 20 permit tcp source any gt 0 destination [Link]/32 eq 179
rule 30 permit tcp source any gt 0 destination [Link]/32 eq 443
exit

security
cpu-defend-policy
white-list mode disable
black-list mode enable ! eanble black list
black-list acl Block-BGP ! associate the black list rule
cp-car mode enable
cp-car rule ospf-bandwidth 30000
..
..
cp-car rule default-bandwidth 1000
exit
exit
​
NOTE: The permit statement is used instead of deny in the blacklist ACL because the blacklist itself
implies a deny action for all traffic that matches (i.e., is permitted by) the associated ACL rules.

Syslog Configuration
The vBNG router supports syslog export for NAT, DHCP, abnormal offline, and online fail event logging.
 ●​ For NAT logging, the configuration of the syslog is covered in the logging section of the CGNAT
application note. Please follow the link for configuration details.
●​ For DHCP event logging, please refer to the configuration guide in the DHCP section.
●​ For abnormal offline and online fail event syslog logging, configure the under
bras->subscriber-manager as shown in the following example
bras
subscriber-manage
user-group-identify circuit
offline-speed 1000
session abnormal-offline-record 32000
session normal-offline-record 32000
session online-fail-record 32
session abnormal-offline-syslog enable
session abnormal-offline-syslog facility local0
session abnormal-offline-syslog severity warning
session online-fail-syslog enable
session online-fail-syslog facility local0
session online-fail-syslog severity warning
exit
exit

SNMP Configuration
To enable SNMP server on netElastic’s vBNG, login to confd and follow the following reference
configuration. By default, the community string on netElastic’s snmp server is set to “public”.

! enable snmp
snmp-server agent enabled
! enable outband snmp and set snmp port number
snmp-server agent out-band enable true
snmp-server agent out-band port 161
! enable inband snmp, set snmp port number, and bind to an inband interface
snmp-server agent in-band enable true
snmp-server agent in-band port 161
snmp-server agent in-band bind interface gei-1/1/1.800
! enable/disable appropriate snmp versions
snmp-server version v1 true
snmp-server version v2c true
snmp-server version v3 true
! set max snmp packet size
snmp-server packet-max-size 50000
! enable/disable snmp event trap notification (no server ACK expected)
snmp-server trap enable
! enable/disable snmp event inform notification (require server ACK)
snmp-server inform enable
! define a snmp community and associate it with a defined snmp view
snmp-server community public view-name public-view rw
! define a snmp view and associate it with an oid tree
snmp-server view public-view [Link] included
! define snmp trap or inform servers, snmp version, and community name
snmp-server host [Link] udp-port 162 trap-outband version v2c community public
 snmp-server host [Link] udp-port 162 trap-outband version v2c community
publicband version v2c community public

SNMP In-band and Out-band Access

From the sample configuration shown above, you can see that vBNG supports both in-band access
(through vBNG router forwarding ports) and out-band access (through the host management ports). To
enable one, or the other, or both, make sure the corresponding enable switches are set to true. The
in-band or out-band ports configured mean that the vBNG SNMP agent will only accept connections
whose source ports match the ports configured.

SNMP Trap/Inform
The router supports sending SNMP event notifications to SNMP servers in both trap mode (no
acknowledgment required) and inform mode (SNMP server acknowledgment required). To configure
SNMP traps, you need to configure the following:
●​ enable snmp agent ​
snmp-server agent enabled
●​ enable snmp trap or inform​
snmp-server trap/inform enable
●​ configure snmp servers. You can configure multiple servers ​
snmp-server host [snmp server IP] udp-port [snmp trap udp port number]
trap-outband/trap-inband/inform-outband/inform-inband version [v1/v2c/v3]
community [community string]

Protect Router Against Attacks via SNMP In-band Connections

SNMP uses both UDP port 161 and port 162 for sending commands and messages. To protect the router
against malicious attacks on the SNMP ports from the in-band connections, you should always protect all
incoming ports with an ACL rule that is designed to block all traffic with SNMP ports except those from
known IPs. Here is a sample configuration

! define an acl to block all connections with port 161 and 162
! except those from [Link]
access-list snmp-protector
rule 10 permit udp source [Link]/32 gt 0 destination any range 161 162
rule 20 deny udp source any gt 0 destination any range 161 162
exit

! bind the acl to all interfaces that could potentially have

! incoming connections
interface 100gei-1/1/0
bind acl in ipv4 snmp-protector
ipv4 address [Link] 30
 exit
interface 100gei-1/1/0
bind acl in ipv4 snmp-protector
ipv4 address [Link] 30
exit

Load netElastic’s SNMP MIB Files

netElastic MIB files come with every vBNG version release package. MIB files could change from version
to version. It is important to get the MIB files that exactly match the router version that you are running.
You can use the command “show sys-info” to display the current router version.
Follow this link to download the MIB files that match your router version. If the MIB files that correspond to
your version can not be found, please email support@[Link].

After downloading the netElastic MIB package, unpack it, you will find
●​ The folder named “netelastic” contains all netElastic MIB object files for the particular version
●​ The netElastic MIB OID list that shows the mapping between OID and the object name.

To load the MIB files depends on the SNMP client you use, please refer to the user guide of the SNMP
client you use on how to load third party MIB files. Here is an example on how to load MIBs if you are
using net-snmp and net-snmp-utils packages on CentOS.
1.​ Copy the netElastic MIBs to /usr/share/snmp/mibs folder. If the folder does not already exist,
create it.
2.​ Create a snmp configuration file [Link] under the /etc/snmp directory. If the folder
does not already exist, create it.
3.​ Add a line with “mibs +ALL” to the [Link] file. If you prefer to selectively add individual
MIBS instead of adding them all, you can add them one by one in [Link] as shown below.​
mibs +NETELASTIC-FLEXBNG-ALARM​
mibs +NETELASTIC-FLEXBNG-IPPOOL ​
…

Test SNMP server by snmpwalk.

If the command “snmpwalk” is not present, run “yum install -y net-snmp net-snmp-utils” to
install the net-snmp package. If you have installed net-snmp-utils packages, you can use snmpwalk to
test the SNMP server access. Here is an example.

snmpwalk -v2c -Of -c public [Link] [Link].4.1.54268.[Link]

In this example, I used local loopback IP as I installed snmpwalk on the same host where vBNG is
installed. I used OID [Link].4.1.54268.[Link] as the base OID prefix for smgr session summary
information. All objects whose OID starts with [Link].4.1.54268.[Link] will be displayed. If you
load netElastic’s MIB correctly, you should see netElastic’s OID objects printed out as shown below.

[root@netelastic ~]# snmpwalk -v2c -Of -c public [Link] [Link].4.1.54268.[Link]

.[Link].0 = Gauge32: 2
 .[Link].0 = Gauge32: 0
.[Link].l2tp-lac.0 = Gauge32: 0
.[Link].0 = Gauge32: 0
.[Link]-line.0 = Gauge32: 0
.[Link].0 = Gauge32: 0
.[Link].l2tp-lns.0 = Gauge32: 0
.[Link]-types.0 = Gauge32: 2

We know from the netElastic OID table that the OID for smgr session summary all and ipoe are:

●​ [Link].4.1.54268.[Link].20 -> smgr-session summary all user count

●​ [Link].4.1.54268.[Link].1 -> smgr-session summary ipoe user count

You can use snmpget to query these specific field values as shown below.

[root@netelastic ~]# snmpget -v2c -c public [Link] [Link].4.1.54268.[Link].20.0

NETELASTIC-FLEXBNG-SMGR::all-types.0 = Gauge32: 2
[root@netelastic ~]# snmpget -v2c -c public [Link] [Link].4.1.54268.[Link].1.0
NETELASTIC-FLEXBNG-SMGR::ipoe.0 = Gauge32: 2

Zabbix Templates.
For SMNP monitoring with Zabbix, here are two reference Zabbix templates
●​ Zabbix netElastic Main Template
●​ Zabbix netElastic Template with Per Subscriber Stats

SNMP Security.
Although the router supports both in-band and out-of-band SNMP access, it is recommended that you
disable the one you are not using by setting the corresponding command: ​
“snmp-server agent in-band/out-band enable false”

You should also create a FlexLink access list to allow SNMP access only from trusted clients. This rule
can be applied to both in-band and out-of-band connections. The following configuration example
illustrates how to do this.

! define a flexlink access list to only allow access from

! known snmp clients
flexlink access-list
rule snmp-client-acl
global deny all
ip-prefix [Link]/32 permit ! known trusted client IP
ip-prefix [Link]/30 permit ! known trusted client prefix
exit
exit

snmp-server agent enabled

snmp-server agent out-band enable false
snmp-server agent out-band port 161
 ! bind the flexlink ACL for out-band access
snmp-server agent out-band bind acl snmp-client-acl
snmp-server agent in-band enable true
snmp-server agent in-band port 161
! bind the flexlink ACL for in-band access
snmp-server agent in-band bind acl snmp-client-aclnt-acl

SNMP troubleshooting.
The SNMP module is part of the confd process. It runs in the host Linux system and can serve
out-of-band SNMP connections natively through the host IPStack. Meanwhile in-band SNMP connections
need to be translated and forwarded to the confd process by a special process in the router called
flexlink. This extra translation adds to processing inefficiency. Therefore, it is recommended to
always use out-of-band SNMP connections when available.

Follow these steps if snmp query does not produce any output

●​ You can use the show snmp host, show snmp view commands to ensure snmp
configuration is taken properly by the router and host and view specifications are correct. If
everything looks right, you can do a local snmp walk to prove snmp information can be retrieved.
●​ For inband SNMP, make sure to add “snmp-server agent in-band bind interface
[interface]” so that the control plane does not have ambiguity on which interface to choose to
send snmp messages.
●​ If using inband SNMP, type “show flexlink” to see if there is an entry for snmp-inband in
flexlink which is the conduit between inband interface and confd snmp module. If examination of
the log file is warranted, it is located at /var/log/certus/go/flexlink/[Link].
●​ If you are using out-of-band SNMP and SNMP queries are not working, follow these
troubleshooting steps:
○​ Run the command netstat -tulnp | grep ':161' on the host linux system to
ensure the process “flexlink” is the only process that is listening on port 161. If there
are other running processes listening on port 161, stop those processes. For example, if
the process “snmpd” is also running and listening on port 161, you can stop the process
by systemctl stop snmpd followed by systemctl disable snmpd.
○​ Capture traffic on the outband interface to verify whether SNMP requests are arriving:.
For example “tcpdump -i eth0 udp port 161”
○​ If SNMP requests are arriving but queries are still unsuccessful, check firewall rules to
ensure SNMP traffic is not being blocked: Run the command “iptables -L” to list all
iptables rules to make sure there are no firewall rules that are blocking SNMP queries.
You can test this by temporarily flushing all firewall rules to remove any potential
restrictions by running the command: “iptables -F”
Interface Management

Create/manage VLAN Interfaces

To create a vlan (dot1q, qinq, or qinqinq) interface, first get into config mode, and then type interface
[parent interface].[integer]. For example, if you want to create a vlan interface off parent
interface 10gei-1/1/1 with dot1q vlan 100, you can create the interface by following these simple steps as
shown below.

domain# config
Entering configuration mode terminal
domain(config)#
domain(config)# interface 10gei-1/1/1.100
domain(config-interface-10gei-1/1/1.100)# dot1q 100
domain(config-interface-10gei-1/1/1.100)# sh fu
interface 10gei-1/1/1.100
bind acl out ipv4 spam-dst-block-list
dot1q 100
exit

NOTE 1: The [integer] portion in the sub interface name does not have to be the same as vlan ID. It
can be any integer from 1 to 4094. As a matter of fact, you can put multiple vlans under one subinterface
as shown in the following examples. Also you can not mix dot1q with qinq under one interface.
NOTE 2: For qinq configurations, the internal means the C-tag and external means the S-tag.
NOTE 3: For either dot1q or qinq tagging, you can use dot1q-range or qinq-range to specify a
range of vlan values instead of listing them out individually.
NOTE 4: You can optionally use the command “phys-address <HH:HH:HH:HH:HH:HH MAC-addr>”
to specify the MAC address of the subinterface to be different from the MAC of its parent physical
interface. If “phys-address” is not specified, the MAC of the subinterface will be the same as that of its
parent physical interface.

! dot1q interface with multiple vlans

interface 10gei-1/1/1.300
dot1q 200
dot1q 300
dot1q 500
exit

! dot1q interface with valn ranges

interface 10gei-1/1/1.100
dot1q 105
dot1q-range 120 to 130
dot1q-range 150 to 160
exit

! qinq interface with multiple vlans

interface 10gei-1/1/1.4094
qinq internal 200 external 4094
qinq internal 300 external 4090
qinq internal 300 external 4094
exit
 ! qinq interface with vlan ranges
interface 10gei-1/1/1.4094
qinq-range internal 200 to 205 external 2000 to 3000
exit

! qinqinq interface with vlan ranges

interface 40gei-1/1/1.1
description "qinqinq access interface"
ip tcp adjust-mss 1410
qinqinq-range outmost 2200 to 2321 preoutmost 1 to 4094 inmost 1 to 4094
exit

NOTE about QinQinQ sub interfaces:

netElastic vRouter supports vlan interfaces with three layers of vlan tags. You can specify a specific3
layered vlan combination with the command qinqinq or you can use the command qinqinq-range to
specify the vlan ranges for each of the three layers of vlans. In either case:
●​ inmost - specifies the inner most (closest to payload) vlan tag or range. The valid range for this
layer is between 1 and 4094. The vlan type for this layer is always 0x8100
●​ preoutmost- specifies the middle vlan tag or range. The valid range for this layer is between 1
and 4094. The vlan type for this layer is always 0x8100
●​ outmost - specifies the outermost (furthest from the payload) vlan tag or range. The valid range
for this layer is between 1 and 4094. The vlan type for this layer depends on the qinq-protocol
setting on the sub-interface. If the qinq-protocol setting is 88a8, the vlan type for this layer
will be 0x88a8. If the qinq-protocol setting is 8100,, the vlan type for this layer will be 0x8100

To check interface status, use the command “show if-management-status”

Create/manage eth-trunk/port channel/lacp Interface
interface eth-trunk1
trunk-mode manual
balance ip-full
trunk-port 10gei-1/1/0
exit
trunk-port 10gei-1/1/2
exit
exit

interface eth-trunk2
description "network interface"
bind acl in ipv4 DNS-INT-ACL
bind acl out ipv4 DNS-INT-ACL
bind qos in policy_interface_queue
bind qos out policy_interface_queue
nat outside
trunk-mode manual
balance ip-full
trunk-port 10gei-1/1/1
exit
trunk-port 10gei-1/1/3
exit
ipv4 address [Link] 30
exit

NOTE 1: It is recommended to set trunk-mode to manual as shown in the example for increased
stability. However you can also set it to lacp-static if you need to accommodate hot interface
changes.
NOTE 2: To change the trunk mode, all member interfaces must be removed from the trunk interface first.
After changing the trunk mode, the member interfaces can be added back.

Here is a sample corresponding Cisco switch [Link] work with vBNG trunk interface
configuration. On the Cisco switch side, the interfaces are GigabitEthernet1/0/5
and GigabitEthernet1/0/6

interface Port-channel2
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 101,102,600,2347
switchport mode trunk
no negotiate auto

interface GigabitEthernet1/0/5
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 101,102,600,2347
switchport mode trunk
 channel-group 2 mode passive

interface GigabitEthernet1/0/6
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 101,102,600,2347
switchport mode trunk
channel-group 2 mode passive

To show trunk status information, use the command “show trunk-info”

After trunk interfaces are created, you can create vlan interfaces based on the created trunk interfaces
the same way as you would on physical interfaces. Here are some example of of vlan interfaces based
on trunk interfaces
interface eth-trunk1.100
description "vlan 1xx access interface"
dot1q 100
dot1q 105
dot1q-range 120 to 130
exit

Create Loopback Interfaces

Loopback interfaces can be very useful in that they are interfaces representing the router itself without
tying to any physical interfaces. Loopback interfaces are commonly used in BGP to represent the router
itself.

To configure a loopback interface, follow these steps.

1.​ Type “confg” to get into configuration mode.
2.​ Type “interface loopback[x]”, where x is an integer representing the loopback interface
ID.
3.​ Optionally you can configure IP addresses the same way as you would on any other interfaces.
4.​ Commit the configuration by “commit”

Here is an example of configuring loopback interface loopback0 with IP address [Link].

netelastic# config
Entering configuration mode terminal
netelastic(config)# interface loopback0
netelastic(config-interface-loopback0)# ipv4 address [Link] 32
netelastic(config-interface-loopback0)# commit
Commit complete.
netelastic(config-interface-loopback0)# sh fu
interface loopback0
ipv4 address [Link] 32
exit
netelastic(config-interface-loopback0)#
Interface MTU, PPPoE MRU, TCP/IP MSS Settings

Setup Interface MTU

The interface MTU can be set independently for IPv4 and IPv6. The default value for both is 1500 when
not explicitly configured. Here is an example of setting the IPv4 and IPv6 MTU to 9000.
interface 10gei-1/1/0
mtu 9000
mtu-v6 9000
exit

MTU, PPPoE MRU, and TCP/IP MSS adjustments

It is important to set up the correct MTU size on the interfaces so that optimal throughput is achieved.
Keep the following points in mind when setting up MTU sizes on interfaces:
●​ Input (Rx_ packets with size larger than the interface MTU will be dropped.
●​ Output (TX) packets with size larger than the interface MTU will be [Link] the router.
●​ The size of all MTU settings on interfaces are in L3 IP MTU size
●​ Physical, Trunk, and Subinterfaces can be set to different MTUs. They work independently
without implication to each other. For example, if you set the MTU on a physical interface to
1500, but set the MTU on a subinterface off that physical interface to be 1560, then traffic access
configured on the physical interface will be subject to MTU 1500 and traffic configured on the sub
interface will be subject to 1560 MTU.
●​ For PPPoE connectivity, you want the interface MTU to be at least the MRU setting under the
pppox template + 8 bytes PPPoE header. For example, if the MRU setting in the pppox template
is 1492, your PPPoE access interface MTU should be at least 1492+8=1500 bytes.

You can also set TCP/IP MSS value on an interface with the “ip tcp adjust-mss [mss value]”
configuration. The relationship between MTU and MSS is “MTU - (TCP header + IP header) = MSS”.
Therefore interface MSS should be set to MTU minus the size of a TCP header and an IP header: Since
TCP and IP headers are both 20 bytes long. The default MSS value is 1500 - (20 + 20) = 1460 with the
default MTU value of 1500. If you set MTU smaller than 1500, you need to set MSS to a smaller value
accordingly. Here is a sample MSS configuration on an interface.

interface 10gei-1/1/0.1000
description "PPPoE Access Interface"
ip tcp adjust-mss 1436
dot1q 1000
exit

Test Link MTU With Ping Test

You can test the router’s MTU by doing a ping test with the packet payload size option. For example, if
the WAN Interface MTU is set to 1500, you should be able to ping out with 1472-byte payload (1500 - 20
bytes IP header - 8 bytes ICMP header), but you should not be able to ping out with 1473-byte payload
packets as illustrated in the following demonstration

netelastic# ping [Link] size 1472

Sending 5, 1480-byte ICMP Echos to [Link], timeout is 2s:
!!!!!
--- ping statistics ---
5 packets transmitted, 5 received, 0.00% packet loss
round-trip min/avg/max = 6/6/7 ms

netelastic# ping [Link] size 1473

Sending 5, 1481-byte ICMP Echos to [Link], timeout is 2s:
.....
--- ping statistics ---
5 packets transmitted, 0 received, 100.00% packet loss

Assigning multiple IPs on an interface

If multiple IP addresses need to be assigned on the interface. Except the primary address, the other
addresses will be assigned as second IP addresses as shown in the following example.

interface vgi1
description vgi
nat inside
ipv4 address [Link] 24
ipv4 address [Link] 24 secondary
exit

QinQ and 802.1ad Settings

The router supports both QinQ and QinQ range for you to conveniently configure QinQ tags. Here are a
few extra pointers for QinQ configurations:
●​ The inner tag is the tag which is closest to the payload portion of the frame; it is officially called
C-TAG (Customer tag, with ethertype 0x8100).
●​ The outer tag is the one closer/closest to the Ethernet header; its name is S-TAG (Service tag,
ethertype 0x88a8). This outer tag can also has ethertype 0x8100
●​ For QinQ, we support both protocol 0x8100 and 0x88a8. If the QinQ VLANs are encapsulated in
802.1ad format, you should set the qinq-protocol to 88a8
○​ When qinq-protocol is set to 88a8, it only affects the outer vlan tag type. The inner
vlan type will still be 0x8100.
○​ The qinq-protocol setting also affects QinQinQ tagged frames. As in QinQ, it only
affects the outmost tag type. The tag type for the two inner vlans will still be 0x8100

ARP Related Configurations

By default the router will respond to ARP requests and populate its ARP table based on the learned ARP
entries. The router provides several ARP configurations that allow you to configure the router’s ARP
Learning behavior to suit the network environment that the router is in. The following are commonly used
ARP related commands:
●​ show arp-table all: Displays the current ARP table on the router.
●​ arp force-learn interface [interface]: Force the router to add ARP entries learned
from the specified interface when the ARP requests are initiated from connected devices. By
default, the router only adds to the ARP table the entries learned by ARP requests initiated by the
router. ARP entries learned from responding to ARP requests from connected devices will not be
added to the ARP table unless “arp force-learn interface” is set for that interface. For
example, setting “arp force-learn interface 100gei-1/1/1” will force the router to add
ARP entries learned by responding to ARP requests from the interface 100gei-1/1/1.
●​ arp expire-time [expire time]: This sets the ARP expiration time in seconds. The
default value is 1200 seconds.
●​ arp proxy: Configure the interfaces on which arp proxy will be enabled. All ARP requests from
any of the interfaces configured under the arp proxy for any IP address that are visible in the
router’s routing table will be responded by the router as if those IP addresses are directly
configured on those interfaces. Here is an example of arp proxy configuration.
arp proxy
interface 10gei-1/1/0.122
interface 10gei-1/1/2
exit
●​ arp gratuitous interface [interface] interval [interval]: Configure to send
gratuitous ARP message on the configured interface at the configured interval. For example, the
configuration of “arp gratuitous interface 10gei-1/1/1 interval 30” will let the
router send gratuitous ARP messages from the interface 10gei-1/1/1 once every 30 seconds.
●​ arp static [ip] [mac]: Configure static ARP entries on the router’s ARP table.

Configure ACL on an interface.

You can use acl to define access rules based on flow characteristics and apply to interfaces. You can
independently apply access control in either the “in” (meaning coming into the interface ) direction or the
“out” (meaning leaving the interface) direction or both. Here is a configuration example.

access-list wan-inf-acl-inbound ! define inbound acl

rule 10 deny specify 1 source any destination any ! block icmp
rule 20 deny ip source [Link]/32 destination any ! block from one ip
rule 50 permit ip source any destination any
exit

access-list wan-inf-acl-outbound ! define outbound acl

rule 10 deny ip source any destination [Link]/32
! the follow two rules block all tcp and udp traffic from the
! specified address on port 143 to any destination
rule 20 deny tcp source [Link]/32 eq 143 destination any
rule 30 deny udp source [Link]/32 eq 143 destination any
rule 40 deny tcp source any gt 0 destination any eq 25 ! block egress smtp
rule 90 permit ip source any destination any
exit
 interface 10gei-1/1/3 ! router wan interface
description "network interface"
bind acl in ipv4 wan-inf-acl-inbound ! apply inbound acl to inf
bind acl out ipv4 wan-inf-acl-outbound ! apply outbound acl to inf
ipv4 address [Link] 24
exit

Configure Rate Limiter QoS on an interface

Sometimes you need to define rate controls for upload and download traffic on specific interfaces. The
rate control can consist of different rates for different flows specified by classmap rules. The configuration
in general involves the following steps:
●​ Define flows by ACL
●​ Create classmaps that match the flows specified by the ACLs defined.
●​ Create rate limiter CAR behavior for the various flows.
●​ Create input and output policies that bind the classmaps together with corresponding behaviors.
The input policy controls the traffic going into the interface and the output policy controls the traffic
leaving the interfaces.
●​ Bind the input and output policies to the desired interfaces

Next, we will use an example to illustrate the configuration. The rate control requirements in this example
are:
●​ Download/upload traffic on WAN interface 10gei-1/1/1.200 for CDN cache is 200/50Mbps
●​ Download/upload traffic on WAN interface 10gei-1/1/1.200 for internet is 100/20Mbps

Here are the configurations

! define cdn acl

access-list cdn-acl
rule 10 permit ip source any destination [Link]/28
rule 20 permit ip source [Link]/28 destination any
rule 100 deny ip source any destination any
exit

! define cdn traffic classmap

class_map cdn-class match-way match-any
match ipv4-access-list cdn-acl
exit

! define internet traffic classmap

class_map all-traffic match-way match-any
match all
exit

! define CAR behaviors for 200,100,50, and 20Mbps

behavior CAR_200Mbps
item 1
car cir 200000 pir 200000 cbs 25000000 pbs 25000000
exit
exit
behavior CAR_100Mbps
 item 1
car cir 100000 pir 100000 cbs 12500000 pbs 12500000
exit
exit
behavior CAR_50Mbps
item 1
car cir 50000 pir 50000 cbs 6250000 pbs 6250000
exit
exit
behavior CAR_20Mbps
item 1
car cir 20000 pir 20000 cbs 2500000 pbs 2500000
exit
exit

! define input and output rate control policies

policy input-policy
class_map cdn-class behavior CAR_200Mbps priority 2
class_map all-traffic behavior CAR_100Mbps priority 1
exit
policy output-policy
class_map cdn-class behavior CAR_50Mbps priority 2
class_map all-traffic behavior CAR_20Mbps priority 1
exit

! apply rate control policies to the interface

interface 10gei-1/1/1.200
bind qos in input-policy
bind qos out output-policy
exit

Configure Shaping on an interface

You can create a QoS policy with traffic shaping rate and apply it to the outbound traffic flow of interfaces.
Outbound traffic flow means uploading traffic on network interfaces and downloading traffic on the access
interface. The application of shaping traffic on interfaces usually falls into two categories:
●​ shaping with rate limit on all traffic flows.
●​ shaping with one group rate limit, but different rate limits for different traffic flows.
Next, we will discuss these two use case scenarios with examples.

Shaping with a single rate limit on all traffic flows.

In this case, the router will create one shaping buffer queue and all traffic flows are subject to the same
rate limit The following example shows 1G download shaping on an access interface and 500M upload
shaping on a network interface.

! shaping policy for 1G throughput

! the rate is in kbps, and burst_size is observation period in ms
 policy shaper-1G
port_shaping rate 1000000 burst_size 5
exit

! shaping policy for 500M throughput

! the rate is in kbps, and burst_size is observation period in ms
policy shaper-500M
port_shaping rate 500000 burst_size 10
exit

! add shaper on an access interface for 1G download

interface 10gei-1/1/1.561
bind qos out shaper-1G
dot1q 561
exit

! add shaper on a network interface for 500M upload

interface 10gei-1/1/0
bind qos out shaper-500M
exit

NOTE: As shown above shaping is only relevant for egress traffic on appropriate interfaces. Shaping
for ingress traffic is irrelevant. As long as the processing capacity is not exceeded, all ingress traffic will
be processed.

Shaping with group rate limit, but separate max rates for different flows.
In this case, you have more than one flow competing for the same total interface bandwidth and each
flow shall have its own max limit when interface bandwidth limit is reached. The router will realize this
by creating a shaper buffer with multiple weighted fair queues. The netElastic vRouter supports 4
weighted fair queues per buffer instance. The weighted fair queues are AF1, AF2, AF3, and AF4 with
weight 1, 2, 3, 4 respectively. For example, if AF1 is used for flow1 and AF3 is used for flow2, flow1 will
get 1/(1+3) = 1/4 of the total bandwidth and flow2 will get 3/(1+3)=3/4 of the total bandwidth. Similarly, if
AF1 and AF2 is used for flow1 and AF3 and AF4 is used for flow2, flow1 will get (1+2)/(1+2+3+4) = 3/10
of the total bandwidth and flow2 will get (3+4)/(1+2+3+4)=7/10 of the total bandwidth.

Here is an example with the following requirements:

●​ There are two flows, local cache and internet.
●​ The total combined interface bandwidth is 150Mbps
●​ When interface bandwidth is maxed out, internet bandwidth can not exceed 50Mbps and local
cache bandwidth can not exceed 100Mbps.
●​ Local bandwidth can use all the 150Mbps as long as max 50Mbps internet bandwidth is
guaranteed for internet traffic. (i.e. local cache can use 150Mbps if there is no internet traffic)
●​ Internet bandwidth can use all the 150Mbps as long as max 100Mbps local cache bandwidth is
guaranteed for local cache traffic. (i.e. internet traffic can use 150Mbps if there is no local cache
traffic)
 To achieve these requirements, we need to:
●​ Create a shaper policy and set the max rate to 150Mbps.
●​ Since the ratio between local cache and internet traffic is 2:1, we can pick two weighted fair
queues that have this weight ratio. In this example, we use queue AF4 for local cache traffic and
AF2 for internet traffic. We set the max bandwidth to 150Mbps for both AF2 and AF4 so each of
them can independently reach the max 150Mbps as long as the competing traffic’s bandwidth is
guaranteed.
●​ Apply the policies to the applicable interfaces in the egress directions.

Here are the sample configurations where traffic flows (class_map) traffic_localCache and
traffic_internet are for illustration purpose only and not explicitly defined

! define the queue for local cache traffic

behavior local_cache_queue
item 1
cbq queue af4 bandwidth 150000
exit
exit

! define the queue for internet traffic

behavior internet_queue
item 1
cbq queue af2 bandwidth 150000
exit
exit

! define shaper policy

policy traffic_queues_shaper
port_shaping rate 150000
class_map traffic_local_cache behavior local_cache_queue priority 7
class_map traffic_internet behavior internet_queue priority 2
exit

! add shaper on an access interface for 1G download

interface 10gei-1/1/1.561
bind qos out traffic_queues_shaper
dot1q 561
exit

Enable PPPoE/DHCP Client on Interfaces

In addition to configuring static addresses, you can set up an interface as a PPPoE or DHCP client to
request a dynamic address that is then applied to that interface. The following examples show a DHCP
client enabled on interface 10gei-1/1/0.200 and a PPPoE client enabled on interface 10gei-1/1/0.300.
! enable dhcp client on interface 10gei-1/1/0.200
 bras
wan-configuration
interface 10gei-1/1/0.200
access-type dhcp
exit
exit
exit

! enable pppoe client on interface 10gei-1/1/0.300

bras
wan-configuration
interface 10gei-1/1/0.300
access-type ppp authentication auto user-name testUser password
testUserPassword
exit
exit
exit

To check the DHCP client IP assignment, use the command “show dhcp wan”. If the interface
successfully obtains a DHCP address, the address will be displayed on the interface when you run the
command “show if-management-status”.

Ingress Filtering for Multihomed Networks (RFC 3704)

The router supports Ingress Filtering for Multihomed Networks (RFC 3704) to limit the impact of
distributed denial of service attacks, by denying traffic with spoofed addresses access to the network.
Any interface on the router can be configured in strict mode, where any packet received on that interface
will have its source address checked against the routing table. If the source address indicates that the
packet could not have originated from that interface, the packet will be dropped.

To configure an interface in strict mode, set “unicast-source reachable-via rx” on that

interface. This configuration is optional. If it is not set, or if the interface is explicitly configured with
“unicast-source reachable-via any”, the interface will operate in loose mode. In loose mode, all
packets received on the interface will be processed without verifying whether they are traceable to the
interface.

Check interface stats

You can check the interface stats with the command “show interfaces-state” and its various
options. Here are some commonly used examples.
●​ show if-management-status​
display interfaces and their states
●​ show interfaces-state last-phys-up-time​
show interfaces and their last physical up time.
●​ show interfaces-state phys-address​
show interfaces and their MAC addresses
●​ show interfaces-state linklocal-address​
show interfaces and their IPv6 link local addresses
 ●​ show interfaces-state statistics​
show interface statistics on all interfaces
●​ show interfaces-state 100gei-1/1/1 statistics​
show interface statistic on interface 100gei-1/1/1
●​ show interfaces-state 100gei-1/1/* statistics in-miss-pkts | select
statistics in-pkts | select statistics in-rate-bits​
show interface miss packets, input packet, and input rates on all interface 100gei-1/1/0 and
interface 100gei-1/1/1
●​ show interfaces-state *gei-1/1/* statistics in-rate-bits | select
statistics in-miss-pkts | exclude [.]​
show in rates and missed packets on all physical interfaces excluding sub interfaces
●​ show interfaces-state *gei-1/1/* statistics in-rate-bits | select
statistics in-miss-pkts | csv | exclude [.]​
show in rates and missed packets in csv format on all physical interfaces excluding sub interfaces
●​ show interfaces-state statistics in-rate-bits | include vgi​
show in rates on all vgi interfaces
●​ show interfaces-state statistics in-discards | csv | include eth |
exclude [.]​
show discard packet counts in csv format on all eth-trunk interfaces excluding sub interfaces
●​ show if-drop summary​
Displays a summary of the most recently discarded packets, including basic information such as
source MAC, destination MAC, EtherType, and the reason each packet was dropped.

Check dropped packets stats

When examining interface statistics with the command “show interfaces-state statistics”, you
may see in-discard (dropped) packets being recorded. In-discard (dropped) packets do not necessarily
indicate a router issue. They are packets processed by the data plane but dropped for various reasons,
such as rate limiting, unreachable routes, malformed packets, or possible MTU issues. Analyzing these
packets can provide important clues about network problems.

From release version 1.12.59.B4P18R2, you can display statistics and packet header information for
dropped packets, allowing dropped packets on interfaces to be investigated and examined..
●​ From the router command line, running the command “show if-drop summary” will display a
summary of the most recent dropped packets in the buffer.
●​ You can also capture dropped packets using the script “tools/capture_drop_pkts.sh”,
which saves them to a PCAP file for further offline analysis.

IPv4 Pool Configuration

One of the essential functionality of a BNG router is IP address allocation to subscribers. Except for a few
use cases (e.g. iphost access) where subscribers manually enter IPs to their devices connected to the
BNG router, subscribers normally need to be assigned an IP from the BNG router whether they are
connecting through PPPoE, DHCP/IPoE or other connection methods. The IPv4 IP space allocation for
subscribers is primarily done through the configuration of IP pools.

Typical IPv4 Pool Configuration

A typical IPv4 pool configuration is shown below.
ippool group localPool
gateway-ip [Link] gateway-mask [Link]
lease-time ​ 600
dns-primary [Link] secondary [Link]
ippool-status ​ unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]​
! optionally blocks of IPs can be reserved for external allocation
reserved-section reserved-start-ip [Link] reserved-end-ip [Link]
exit
! optionally MAC/IP mapping can be specified
static-bind e4:b9:7a:88:f1:d5 ip-address [Link]
static-bind e4:b9:7a:88:f1:d6 ip-address [Link]
exit

The key elements of a IPv4 pool configuration are:

gateway-ip and gateway-mask: Here you specify the gateway IP and network mask. This is the
gateway configuration that the BNG router sends to the subscriber device, which will use this information
as its default gateway setting. Normally the gateway setting in the pool definition needs to match the
subscriber’s VGI gateway IP address. For point to point connections such as PPPoE, the gateway IP can
be singular IP with a 32 bit mask.
lease-time: This configures the dhcp lease time in seconds. Please note that the subscriber’s CPE
device normally renews its lease at half of the least-time setting. Please note that the lease time can be
overwritten by the value from radius (under VSA NetElastic-Lease-Time) when the frame-ip lease
manage switch is set to enable. If lease-time is sent from radius or lease-time is defined in the
authorized template AND authorization type is set to radius or mix-radius, the lease-time defined under
the pool will be ignored and the lease time either from radius or locally defined under authorization
template will be used instead.
frame-ip lease manage [disable/enable]: This setting enables or disables allowing the router to accept
subscriber's lease time from radius (under VSA “NetElastic-Lease-Time”). When set to enable, the router
will use the lease time from radius as the subscriber’s lease time. Lease time from radius will be updated
on the next DHCP offer or renewal. When this switch is set to disable, the lease time from radius will be
ignored and the locally configured lease time will always be used.
dns: Here you can configure primary and secondary DNS settings.
section: Here you define the IP block sections. You can define multiple disjoint sections under one ippool
group configuration.

Once an ippool configuration is created, you can use the command “show ippool status | tab” to
display the ippool information. If a pool is successfully created, the pool details should be displayed.
warning-threshold [percentage]: This sets the ippool usage depletion trigger threshold in percentage.
When the ippool usage exceeds this percentage setting, the system will generate a system Warning (level
4) alarm event. For more information, please refer to the alarms and events section.
warning-exhaust [enable/disable]: This switches the enable/disable the generation of a system Critical
(level 2) alarm event when the pool resource is exhausted. For more information, please refer to the
alarms and events section.

IP Reservation and Static MAC/IP Binding

As shown in the above examples, you can optionally configure the IP pool to block certain IP ranges
within a section from being dynamically allocated by the BNG router. You can also use static bind to
achieve static mapping between IP and subscriber’s MAC addresses.

reserved-section: Under each section, you can configure reserved-section to block IP ranges
from which the vBNG router will NOT dynamically allocate any IPs to subscribers. If you are allocating
IPs from radius, it is imperative that you configure reserved-section to block IPs that you are going to
assign from radius.

static-bind: With this feature, you can configure the router to always assign certain IP to subscribers with
certain MAC addresses. Note that the IP addresses bound by static-bind can NOT be under any section
definition and they need to be defined in parallel to section definition. If you need to use static-bind to
bind IPs within a section definition, you need to break the section definition into disjoint sections with the
static IPs excluded as shown in the following example.
ippool group myPrivatePool
gateway-ip [Link] gateway-mask [Link]
frame-pool disable
lease-time 3600
dns-primary [Link] secondary [Link]
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
static-bind aa:bb:cc:dd:ee:f0 ip-address [Link]
static-bind aa:bb:cc:dd:ee:f1 ip-address [Link]
static-bind aa:bb:cc:dd:ee:f3 ip-address [Link]
exit

Using static-bind in the ippool configuration is one of the ways by which you can achieve static IP
assignment. Other static IP assignment methods include iphost and static IP assignment from radius
which we have covered under Framed-Ip assignment. Please note the difference between static bind and
iphost.
●​ iphost: subscribers are allocated IPs from their ISP and the users will have to manually configure
the IPs on their CPE devices. User session on the BNG router is triggered by the ARP requests
from the subscribers.
●​ static-bind: subscribers get IP assignments through the dynamic online process such as PPPoE
or IPoE. User sessions on the BNG router are triggered by the subscribers’ online processes
 during which the BNG router will always assign the same IP to the subscriber by the static-bind
list in the ippool configuration.

Configuring With Multiple Subnet Pools

For typical ISP BNG use cases, you are most likely to encounter situations where you need to assign
customers different IPs depending on customers location or subscription. Two typical use cases are these
are
●​ Some users get private IPs and go through NAT while others get public IPs and need to bypass
NAT. In this case we need to provision a private IP pool and a public IP pool.
●​ You want to assign different IPs from different pools based on customer locations such as
different VLAN access interfaces to better differentiate subscribers.

Configurations with multiple subnet pools are handled differently between PPPoE and IPoE access. This
is because PPPoE is a point-to-point connection where the concept of gateway is arbitrary, while the
gateway is a very important access point for IPoE connections. We will deal with these two cases
separately in the following use case scenarios.

IPoE With Multiple Subnet Pools.

Case I: Multiple Subnets separated by different VLANs

In this case, all subscribers come in under different VLANs so we can create different access sub
interfaces and put them into different domains based on VLANs to differentiate their access domain
binding. Here is how we should configure for this case:
●​ Create a separate IP pool for each vlan/subnet. For each IP pool, create a matching gateway.
●​ Create a corresponding VGI that matches the gateway IP for each IP pool.
●​ Create a separate domain for each vlan/subnet. Bind the corresponding ippool and vgi in each
domain definition.

Case 2: Multiple Subnets sharing the same VLAN access

In this case, all subscribers come in under the same VLAN so we can not put them into different
domains based on VLANs to differentiate their access domain binding. Here is how we should
configure for this case:
●​ Create a separate IP pool for each vlan/subnet. For each IP pool, create a matching gateway.
●​ Create only one VGI whose IP should include all gateway IPs of the configured IP pools. Pick
any gateway IP as the primary and the rest gateway IPs should be configured as secondary IPs
on the VGI interface.
●​ Create one domain. Bind all the ippools and the singular vgi in the domain definition.

Here is an example. Suppose that I am configuring multiple IPoE pools with different subnets as
shown below.
[Link]/24, [Link]/24, [Link]/24, [Link]/24
 You will configure 4 pools with 4 gateways. However, you will only need to configure one VGI. In the
user access domain you will bind all 4 pools and the one VGI. For the VGI interface, you do need to
bind all four gateway IPs to the VGI. You can pick any one gateway IP as the primary and then the
others as secondary as shown in the following example
interface vgi1
description vgi
nat inside
ipv4 address [Link] 24
ipv4 address [Link] 24 secondary
ipv4 address [Link] 24 secondary
ipv4 address [Link] 24 secondary
exit

PPPoE With Multiple Subnet Pools

Since PPPoE are PPP connections and there are no IP broadcast implications. netElastic vRouter
supports using one shared 32-bit gateway for different IP pool subnets. For example, you have two
private pools [Link]/24, [Link]/22, and one public pool [Link]/28. You can use
any 32-bit IP as the gateway for three pools. We use [Link]/32 as the default gateway in this
example. ​

interface vgi1
description vgi
nat inside
ipv4 address [Link] 32
exit

bras
vgi-configuration
interface vgi1
exit
exit
exit

ippool group localPool1

gateway-ip [Link] gateway-mask [Link]
lease-time 60
dns-primary [Link] secondary [Link]
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit

ippool group localPool2

gateway-ip [Link] gateway-mask [Link]
lease-time 60
 dns-primary [Link] secondary [Link]
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit

ippool group publicPool1

gateway-ip [Link] gateway-mask [Link]
lease-time 60
dns-primary [Link] secondary [Link]
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit

IP Pool Modification and Maintenance

It is often required to add/remove IP pool sections to accommodate changing IP pool resource needs as
the network evolves. IP pools can not be changed if there are active user sessions whose IPs are from
the pool that needs to be modified. To modify the pool, you must first free it by clearing all user sessions
associated with that pool.

If the IP pool is configured as part of the BNG services, clearing user sessions will automatically release
the associated IP pool allocations. If the IP pool is configured as part of a standalone DHCP service, or if
there are residual entries in the pool for any reason, the router provides the following commands to reset
the IP pools:
●​ recycle pool-name [pool name] all​
Clears all IPs in the specified pool.
●​ recycle pool-name [pool name] start-ip-address [start ip] end-ip-address
[end ip]​
Clears a block of IPs from the specified pool. To clear a single IP, set the start IP and end IP to
the same value.

Show IP Pool Status

You can check overall IP pool status and pool allocation status for each individual pool with these
commands
●​ show ippool status | tab​
This will list all the defined pools and their pool usage and allocation summary. If an IP pool is
successfully created, you should be able to get a summary view of its state with this command.
 ●​ show ippool detail group [pool name]​
The will list the pool usage detail for each individual IP in the pool

DHCP Configuration
For provision of accepting DHCP/IPoE connections, The DHCP function needs to be configured on the
vBNG router. Please keep in mind that if you need to have IPoE user sessions on the vBNG router,
configuring the DHCP alone is not enough. For IPoE connections and related user management, DHCP
is only part of the IPoE configuration flow. Please consult the IPoE configuration guide for more
information on IPoE configuration.

The DHCP configuration has two parts: global configuration and interface specific configuration. The
vBNG router can be configured either as a DHCP server or as a relay agent at each interface level. The
global configuration of DHCP has the following main parameters:

●​ dhcp enable/disable - this is a global switch to enable or disable dhcp service.

●​ relay optino82 [format/option/uniform] - provides the option to configure how to insert
option 82 fields when vBNG is configured as relay agent
●​ ramble - controls whether to allow dhcp clients to roam. When configured, dhcp clients can
roam across vlans. vBNG router will maintain the user session’s validity as long as the user’s
requests have the same MAC regardless of their vlan.
●​ policy - define dhcp policies where can specify various dhcp options such as option 3, 33, 121,
125 etc. The defined policies can be applied to interfaces where either dhcp server or relay agent
is enabled. Explanations and examples on how to define and apply dhcp policies are presented
later.

DHCP Configured as a Server

DHCP server as part of IPoE access

When DHCP is enabled for IPoE access, the vBNG can serve as the DHCP server for incoming
DHCP/IPoE connections. A typical DHCP server configuration for this mode is shown below.

dhcp
dhcp enable
relay max-user 128000
relay option82 policy ​ keep
relay option82 format ​ dsl-forum
relay option82 user-configuration-policy interface
interface gei-1/1/2
mode ​ server
user-quota 128000​
reauth when-lease-renew ! enable dhcp renew authentication
exit
exit
DHCP renew trigger user re-authentication with IPoE access
In scenarios where periodic validation of user subscriptions is required, re-authenticating users
against the RADIUS database upon each DHCP renewal message can be an effective approach.
Starting from release version 1.12.55.B3P34, you can configure the router to trigger user
re-authentication upon receiving a DHCP renew message. To enable this feature, apply the following
configuration to the interface through which the user's DHCP requests are received, as shown in the
example above. ​
dhcp -> interface [interface name] -> reauth when-lease-renew

DHCP as standalone server for L2 connected clients

In addition to setting up a DHCP server as part of the IPoE online access, you can also use vBNG as
a standalone dhcp server to serve dhcp requests on the enabled interfaces as shown in the following
example. In this case, dhcp requests will not be authenticated and no user sessions will be created
on the vBNG following DHCP offers. To setup standalone DHCP servers, you should
1.​ Configured an IP pool with all the needed elements such as gateway IP, gateway mask, DNS
settings, and IP block sections.
2.​ Identify the interfaces where you need to serve DHCP requests and configure the interface with
the gateway IP address defined in the pool definition.
3.​ Configure DHCP server as shown in the following example, where you can
a.​ add the interface from which the DHCP requests are coming in.
b.​ optionally bind the ip pool under the selected interface as shown in the example.
c.​ optionally bind any applicable DHCP policies as shown in the example

dhcp
dhcp enable
relay max-user 128000
relay option82 policy ​ keep
relay option82 format ​ dsl-forum
relay option82 user-configuration-policy interface
interface gei-1/1/2
mode ​ server
user-quota 128000
pool ​ localPool ! optionally bind a pool on this interface
dhcp-policy customized-route-policy
exit
policy customized-route-policy
option33-route [Link] [Link]
exit
exit

A few things to keep in mind with dhcp server configuration:

●​ You can apply a dhcp policy for all requests to the interface where the dhcp server is enabled
as shown in the above example.
●​ If you want the users to roam across vlans, you need to turn on ramble as explained earlier.
 ●​ You can optionally bind an ip pool as shown in the above example if you want to use vBNG as
a standalone dhcp server to serve dhcp requests on the enabled interfaces. However, if you
want to have user session management on the vBNG router and setup DHCP server as part of
the IPoE online process,, you should NOT bind any ip pool under the DHCP configuration.
Instead you should follow the IPoE configuration flow where the ip pools are bound under the
access domain for IPoE.
●​ If you want to statically bind IPs to certain MAC addresses, you can achieve this by creating a
MAC to IP binding table in the corresponding IP pool definition. See this section for more
details.
●​ When connected with a DHCP relay agent, the DHCP server will have to work in L3 relay
mode. Our DHCP server implementation does not work with L3 DHCP relay agents until
version 1.12.59.B4P18. See the notes below on how to set up the DHCP server to work with a
relay agent.

DHCP Broadcast Flag Override

The DHCP broadcast flag bit is set by a client to indicate to a server how the reply should be sent
back to the client. The DHCP client sends its request by broadcast, initially, since it doesn't know the
server's IP address. However, since the server knows the client's IP (it just provided it with one), the
server can send the reply back by unicast even if the request was sent by broadcast. Therefore the
DHCP server can send to the DHCP offer either by broadcast or by unicast even if the client’s request
specifies the reply should be in broadcast mode by setting the broadcast flag bit to 1.

From version 1.12.59.B4P18, the route provides the option to reply with unicast even if the client sets
the broadcast flag bit by adding the switch “broadcast-bit-override” in DHCP server
configuration. When this configuration is enabled, the DHCP server will reply to the client with the
dhcp offer in unicast even if the broadcast flag is set to 1 in dhcp request. When enabled, you can
subsequently set a broadcast bit overwrite interval.
○​ broadcast-bit-override disable: the dhcp server will always reply with broadcast if the
broadcast flag in the dhcp request message is set to 1.
○​ broadcast-bit-override enable [interval]: the dhcp server will reply with unicast
per the programmed interval when the broadcast flag in the dhcp request message is set to 1.
The interval value can be programmed with any integer value between 0 and 63. The
interval value shall be interpreted by the following definition
■​ 0 : When the interval is set to zero, all set broadcast flags from clients will be flipped. The
server will always reply with a unicast message regardless of the broadcast bit setting in
the request message.
■​ M (1-63) : When the interval is set to M, the dhcp server will honor one broadcast flag
every M requests where the broadcast flag is set to 1, the other M-1 requests will be
replied with unicast. For example if the interval is set to 8, the dhcp server will reply with
1 broadcast message and 7 unicast messages for every 8 requests where the broadcast
flag is set to 1.

DHCP as standalone server for clients through a relay agent

From version 1.12.59.B4P18, the router supports configuring the router as a standalone dhcp server
serving IPs to clients behind a L3 connected relay agent proxy. Below is a sample configuration
 dhcp
dhcp enable
dhcp-syslog disable
dhcp-syslog facility local0
dhcp-syslog severity info
relay max-user 128000
relay option82 policy ​ keep
relay option82 format ​ dsl-forum
relay option82 user-configuration-policy interface
interface 10gei-1/1/0.3009 !interface that collects to the relay agent
mode ​ server
user-quota 128000
dhcp-policy option43
pool ​ private-ipv4-pool-no-bng
broadcast-bit-override disable
exit
policy option43
reply-option 43 string [Link]
exit
exit

ippool group private-ipv4-pool-no-bng

gateway-ip [Link] gateway-mask [Link]
frame-pool ​ disable
lease-time ​ 360
dns-primary [Link]
ippool-status ​ unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit

interface 10gei-1/1/0.3009 !interface that collects to the relay agent

description lab-test-vlan
mtu ​ 9000
nat inside
ipv4 address [Link] 31
ipv6 enable
ipv6 address 2001:1900:2300:a300:10:127:255:14 127
dot1q 3009
exit

NOTES:
1.​ The pool binding under dhcp -> interface is optional. The pool binding is only necessary
when the router is configured as a DHCP relay agent.
2.​ When the router is set up as a standalone server for clients through a relay agent, it can serve
clients from multiple pools. To set this up, you will need to configure multiple IP pools on the
router with each pool having its own gateway AND make sure no pool is bound under dhcp ->
 interface configuration. The router knows how to resolve IP allocation from the appropriate
pool based on the following logic:
a.​ When the relay agent forwards a client’s request to the DHCP server, it sets the giaddr
field to its own IP address (the IP of the interface that received the client’s request).
b.​ When the DHCP server receives the discovery packet from the relay agent, it checks the
giaddr value to determine which subnet the client belongs to. Based on this, the server
allocates an IP address from the corresponding IP pool.
c.​ In summary, the DHCP server assigns an address from the pool whose gateway matches
the giaddr value in the discovery packet from the relay agent.

DHCP event logging with syslog.

From version 1.12.59.B4P18, you can configure to export DHCP logs to external syslog servers when
the router is configured as a DHCP server. To add syslog support for dhcp logs. To enable dhcp
syslog, add the following configuration to the dhcp module configuration
dhcp
dhcp enable
dhcp-syslog enable
dhcp-syslog facility local0
dhcp-syslog severity info
exit
○​ Keep in mind that syslog facility and severity can be configured independently under dhcp-syslog
and globally under syslog. The relationship between dhcp-ssylog facility/severity and global
syslog facility and severity configurations are the following
■​ facility: the facility configured under dhcp-syslog will overwrite the facility configured
under global syslog
■​ severity: dhcp syslog is exported only when the severity configured under dhcp-syslog is
higher than the severity configured under global syslog. For example, if dhcp-syslog
severity is configured to info, the global syslog severity needs to be configured either to
info or all for the dhcp syslog to be generated.
○​ The dhcp syslog format is of the following:
Nov 21 09:44:57 [Link] 1 2024-11-21T01:44:35.106Z domain DHCP 20178
ACCESS-DIAG [ONLINE CLIENT-MAC="00:10:94:00:90:0c"
ACCESS-INTERFACE="10gei-1/1/4.100" IP="[Link]" DHCP-MODE="server"
EVENT-TIME="2024-11-21 09:44:35.106"]

Nov 21 09:57:45 [Link] 1 2024-11-21T01:57:22.286Z domain DHCP 20178

ACCESS-DIAG [RELEASE CLIENT-MAC="00:10:94:00:90:0c"
ACCESS-INTERFACE="10gei-1/1/4.100" IP="[Link]" DHCP-MODE="server"
EVENT-TIME="2024-11-21 09:57:22.285"]

Nov 21 09:44:28 [Link] 1 2024-11-21T01:44:05.946Z domain DHCP 20178

ACCESS-DIAG [RENEW CLIENT-MAC="00:10:94:00:90:0c"
ACCESS-INTERFACE="10gei-1/1/4.100" IP="[Link]" DHCP-MODE="server"
EVENT-TIME="2024-11-21 09:44:05.946"]

Nov 20 16:52:49 [Link] 1 2024-11-20T08:52:27.123Z domain DHCP 20178

ACCESS-DIAG [KICK CLIENT-MAC="00:10:94:00:90:0c"
ACCESS-INTERFACE="10gei-1/1/4.100" IP="[Link]" DHCP-MODE="server"
EVENT-TIME="2024-11-20 16:52:27.123"]
 Nov 14 14:34:11 [Link] 1 2024-11-14T06:34:11.351Z domain DHCP 11971
ACCESS-DIAG [TIMEOUT CLIENT-MAC="00:10:94:00:00:06"
ACCESS-INTERFACE="gei-1/1/2.100" IP="[Link]" DHCP-MODE="server"
EVENT-TIME="2024-11-14 14:34:11.350"]

DHCP Configured as a Relay Agent

DHCP Relay Agent Configuration.

When the vBNG router is configured as a relay agent on an interface, the DHCP requests from that
interface will be forwarded to external DHCP servers. vBNG will subsequently relay the DHCP
responses from the external DHCP servers back to the clients with the option to insert certain DHCP
options. Keep in mind that the BNG router will treat the IP addresses obtained from the external
DHCP server the same way as framed IP addresses from radius servers. Unless the key
frame-pool is set to enable in the ippool definition, the IP addresses from the external DHCP
servers need to be reserved in the ippool definition for the BNG router to assign those IPs to the
clients.

Here is an example of configure the BNG router as a DHCP relay agent

dhcp
dhcp enable
interface eth-trunk21.333
mode relay
relay-lease-proxy 180
relay-agent [Link]​
relay-all-options enable
relay-server-group my-relay-dhcp-server
user-quota 32000
pool my_ipoe_pool
exit
relay-server-group my-relay-dhcp-server
algorithm first
max-retry 3
relay source-ip [Link]
server 1 [Link] standard master
server 2 [Link] standard
exit
exit

The above configuration example can be explained in the following logical configuration steps:

1.​ Define and reference an ip pool (my_ipoe_pool in the example). The pool needs to mirror the
external dhcp server in terms of ip spaces. But all ip spaces on the vBNG need to be reserved
in the ip pool defintion.
2.​ Define a relay-server-group (my-relay-dhcp-server in the example) and reference it under the
dhcp->interface [dhcp access interface]. In the relay server group, you need to
set:
a.​ relay source-ip ( [Link] as in the example), which is the NAS ip to your external
dhcp servers. This IP can be an interface IP or loopback IP from which you should be
able to ping your external dhcp servers. As configured in the example, you should be
able to run “ping [Link] source-address [Link]” from the router and the
ping should go through successfully. Keep in mind that although the connection between
the dhcp relay agent and the external dhcp server is between the relay source-ip
and the external dhcp server IP, the dhcp request source IP (which is the content of the
dhcp request to the external dhcp server) is the relay-agent IP explained below.
Therefore, the destination IP of the reply packets from the external dhcp server will be
relay-agent IP, not relay source-ip. So it is important to make sure that the
external dhcp server has a route to the relay-agent IP.
b.​ algorithm [first/forward-all/round-robin]. Here you specify the algorithm
by which the router forwards dhcp to external servers. There are three options:
i.​ first: The router will forward requests to the server labeled as master first and
will forward requests to other servers only if the first one fails to respond. Please
note if the algorithm is set to first, you have to set one server as master for
dhcp forwarding to happen.
ii.​ forward-all: The router will forward requests to all servers. Whoever
responses first will be relayed to dhcp clients. For this algorithm, you don’t have
to specify a master for the DHCP servers.
iii.​ round-robin: The router will forward requests to the DHCP servers in round
robin fashion. For this algorithm, you don’t have to specify a master for the
DHCP servers.
c.​ server: Here you list all external DHCP servers. You can configure up to 8 servers.
As shown in the above example, if the algorithm is set to first, you have to specify one
server as master.
3.​ Next you list all the interfaces from which you are expecting dhcp requests are coming in. In
the above example "interface eth-trunk21.333 " is the interface where incoming dhcp
packets come in. If you have more interfaces, add all of them under dhcp in similar fashion.
For each interface listed, you need to specify:
a.​ mode: set the mode to relay.
b.​ relay-agent [agent IP]: The relay agent IP is supposed to be the source IP by
which the router is replying to client devices. This IP needs to be within the subnet from
which you will be allocating IP to clients. Not only this IP needs to be reachable to the
external DHCP server IP, but it also does need to be reachable to the clients. For the
BNG use case, the agent IP should be the vgi IP of the connections associated with that
vgi interface. In the above example: [Link] is the vgi IP for connections from interface
eth-trunk21.333.
c.​ relay-all-options [enable/disable]: when set to enable, the router will relay all
DHCP options between the client and the server. This option is supported since version
1.12.59.B4P18.
d.​ pool: bind to the pool defined in step 1:
e.​ relay-server-group: bind to the relay server group defined in step 2
f.​ relay-lease-proxy: set the lease time (in seconds) that the router sent to the client.
If this is not configured, the lease time on the client will be the one set on the external
 DHCP server. You can use this key to shorten the DHCP lease time between the router
and the client while maintaining a longer lease time between the router and the external
DHCP server. For example, if the lease time on the external DHCP server is 24 hours,
and relay-lease-proxy is set to 300, the client will renew lease from the router by
5-minute lease time while the router will renew lease from the external server by 24-hour
lease time.

DHCP Relay Agent Supported Options

When the router is configured as a relay agent, forwarding option messages from the client to the
server and vice versa is not automatic and transparent to the router unless explicitly configured to
pass all options (supported since version 1.12.59.B4P18).

For versions prior to 1.12.59.B4P18 or when relay-all-options is set to disable for version
1.12.59.B4P18 and later versions, each option is handled individually and thus provides the option to
overwrite some of the DHCP options. Future versions will add the option to pass all options between
the client and the server making the router transparent between the client and the server as far as
passing dhcp options is concerned.

Currently the following options are forwarded from the client to the server.

Option code Name meaning

12 Hostname Hostname string

50 Address Request Requested IP Address

53 DHCP Msg Type DHCP Message Type

54 DHCP Server Id DHCP Server Identification

55 Parameter List Parameter Request List

57 DHCP Max Msg Size DHCP Maximum Message Size

60 Class Id Class Identifier

61 Client Id Client Identifier

80 Rapid Commit Rapid Commit

82 Relay Agent Information Relay Agent Information

Currently the following options are forwarded from the server to the client.

Option code Name meaning

1 Subnet Mask Subnet Mask Value

3 Router N/4 Router addresses

6 Domain Server N/4 DNS Server addresses

12 Hostname Hostname string

15 Domain Name The DNS domain name of the client

51 Address Time IP Address Lease Time

53 DHCP Msg Type DHCP Message Type

54 DHCP Server Id DHCP Server Identification

57 DHCP Max Msg Size DHCP Maximum Message Size

 58 Renewal Time DHCP Renewal (T1) Time

59 Rebinding Time DHCP Rebinding (T2) Time

60 Class Id Class Identifier

61 Client Id Client Identifier

66 Server-Name TFTP Server Name

80 Rapid Commit Rapid Commit

82 Relay Agent Information Relay Agent Information

DHCP Relay Agent Troubleshooting.

If the DHCP function is not working property when configured as a relay agent, try the following
debug step:

1.​ Ping the external dhcp server with the configured relay source-ip as the ping source-address. For
example “ping [Link] source-address [Link]” to make sure ping goes through.
2.​ If the algorithm is set to first, make sure you have at least one server set to master.
3.​ Use the command “show dhcp detail info” to display dhcp status information.
4.​ Use the command “show vbras online-fail-record” to display the reasons for user
online failures.

Configure DHCP Policies

You can configure different DHCP policies and apply to an interface to apply the dhcp policy to all dhcp
requests coming to that interface. DHCP policies defined can be applied to clients in both server mode
and relay mode.

Some of the most commonly used options are

●​ dhcp-option125: Use this to send a string or value to the client with this vendor specific option
(option 125)
●​ client-option: use this key to conditionally send reply options depending on if the value sent
in option 60 matches the test value. If there is a match, you can specify to send a reply option of
your choice. Otherwise, no value will be sent.
●​ reply-option: use this key to send a reply option value with any option number.

There are other route related options such as option 3, 33, and 121 that we support. Please refer to the
dhcp policy in the command line prompts for command details.

We will illustrate these more advanced options with a few examples.

Send DHCP Client TR069 URL With Option 43

Suppose the DHCP server needs to send the client aTR069 server URL via option 43 upon an IP
offer, we need to:
1.​ Define a DHCP policy where we can
 a.​ either specify that when option60 string in the DHCP discovery packet matches the
predefined pattern, DHCP server will send a string as option 43. The command format is
“client-option [option60 pattern to match] reply-option [option ID]
string [option string]”
b.​ or specify the DHCP server to send a string as option 43 regardless of matching option60
string or not. The command format is “reply-option [option ID] string
[option string]”
2.​ Apply the policy to the relevant interfaces

NOTE: For this to work, the CPE needs to have option60 field configured with the same matching
string.

Here is a sample DHCP server configuration with these elements highlighted in color.
dhcp
dhcp enable
relay max-user 128000
relay option82 policy keep
relay option82 format dsl-forum
relay option82 user-configuration-policy interface
interface gei-1/1/2
mode server
user-quota 32000
dhcp-policy option43
exit
policy option43
client-option option60Pattern reply-option 43 string
[Link]
! optionally you can specify to return option 43 regardless of
! matching option6 pattern or not
reply-option 43 string [Link]
exit
exit

Send DHCP Client Static Routes With Option 121

You can use option 121 to assign static routes to clients as shown in the following example, in which
the DHCP server enabled on interface 10gei-1/1/0 will send default route and two additional static
routes to the clients. This is achieved by first configuring a dhcp policy with static routes defined
(highlighted in green) and then applying to the appropriate interfaces (highlighted in yellow).

dhcp
dhcp enable
relay max-user 128000
relay option82 policy keep
relay option82 format dsl-forum
relay option82 user-configuration-policy interface
interface 10gei-1/1/0
mode server
 user-quota 32000
dhcp-policy option121-policy
exit
policy option121-policy
option121-route [Link] 0 [Link]
option121-route [Link] 24 [Link]
option121-route [Link] 32 [Link]
exit
exit

Send Provision Server IP With Option 66

Here is an example of using the key reply-option to send tftp server name as option 66 to dhcp
clients. This is only available after router version R.1.7.33B10P2 or later

dhcp
policy provSvr
reply-option 66 string [Link]
exit
interface 10gei-1/1/3.121
mode server
user-quota 32000
dhcp-policy provSvr
exit
exit

Send NTP Server IP With Option 42

Here is an example of using the key reply-option to send server ip as option 42 to dhcp clients.
This is only available after router version R.1.7.33B10P2 or later

dhcp
policy dhcp-ntp
reply-option 42 ip [Link]
exit
interface 10gei-1/1/3.121
mode server
user-quota 32000
dhcp-policy dhcp-ntp
exit
exit

Send With Option 125 and Conditionally Send Option 60

Here is another example of using DHCP policy to send two attributes:
1.​ send a text string to the dhcp client by dhcp option 125.
2.​ if option 60 value matches “testOption60”, then send string “this is a test” to the client with
option 23.
 dhcp
dhcp enable
relay max-user 128000
relay option82 policy keep
relay option82 format china-tel
relay option82 user-configuration-policy interface
interface gei-1/1/2
mode server
user-quota 32000
dhcp-policy dhcp-policy
exit
interface gei-1/1/4
mode server
user-quota 32000
exit
interface gei-1/1/5
mode server
user-quota 32000
exit
policy dhcp-policy
dhcp-option125 enterprise-code 23 option125-string test
client-option testOption60 reply-option 23 string "this is a test"
exit
exit

Check DHCP Status

The command “show dhcp detail | tab” shows dhcp allocation status. You can customize what to
display with the optional select command as shown in the example.

netelastic# show dhcp detail info interface | select ipv4-address | select option60 opt60-ascii | select option82
opt82-cid-ascii | select option82 opt82-rid-ascii | select state | select expiration | select option12 opt12-ascii
OPT82 OPT82​
OPT60 OPT12 CID RID​
VPN IPV4 ASCII ASCII ASCII ASCII​
ID MAC ADDRESS ADDRESS STATE EXPIRATION INTERFACE STRING STRING STRING STRING​
------------------------------------------------------------------------------------------------------------------​
0 00:21:70:d7:d3:ca [Link] BOUND 2021-06-04 19:03:08 gei-1/1/5 MSFT 5.0 lab-PC​
0 e4:b9:7a:88:f1:d5 [Link] BOUND 2021-06-04 19:02:53 gei-1/1/4 MSFT 5.0 Weixiao-PC

Reset DHCP Leases

When the router is configured in server mode, you may occasionally have the need to reset DHCP
leases. The router provides options to reset all DHCP leases or to reset leases by interface, IP address,
or MAC address. Here are some examples.

●​ kick-off dhcp { all }​

clear all dhcp leases
 ●​ kick-off dhcp { interface-name 100gei-1/1/1.300 }​
clear all dhcp leases on a specific interface
●​ kick-off dhcp { ip-address [Link] }​
clear a dhcp lease by its ipv4 address
●​ kick-off dhcp { mac-address aa:bb:cc:dd:ee:ff } ​
clear a dhcp lease by its mac address

Subscriber Access Configuration

A typical use case for vBNG routers is user access management via various access methods such as
PPPoE, IPoE, L2TP, IPhost, etc. To configure the vBNG router for user access management, the best
practice is to start up with listing the router interfaces and map them out to your network design and come
up with a network design topology diagram. To list available router interfaces, use the command “show
if-management-status” as shown in the following example.
netelastic# show if-management-status
​ PHYS​ ADMIN PROTO
INTERFACE NAME ​ADDRESS ​ STATUS STATUS STATUS
-----------------------------------------------------------------------------------
null0 ​- ​ up ​ up ​ up
vgi1 ​[Link]/24 ​ up ​ up ​ up
gei-1/1/0 ​- ​ down​ up ​ down
gei-1/1/1 ​- ​ down​ up ​ down
gei-1/1/1.100 ​- ​ down​ up ​ down
gei-1/1/2 ​- ​ down​ up ​ down
gei-1/1/3 ​[Link]/24 ​ up ​ up ​ up

Understand Subscriber Access Call Flow

When user access initiation packets come into the vBNG, they usually carry the following information.
●​ User credentials, i.e. user name/password and access domain. For PPPoE access, users come
in with username and password in PPPoE discovery packets. For IPoE access user credential
strings usually come in as whole or part of option60 and option 82 strings. vBNG router provides
very flexible ways to extract user name, password, and domain from these strings.
●​ Device ID, this is usually the access device’s MAC address.
●​ Access circuit information. This is usually the VLAN ID carrier inserted in the packets. These
VLAN IDs can either be originated from the access CPE device and/or inserted by the switch or
gpon device between the CPE device and the vBNG router.

The vBNG router user authentication process can be summarized as in the following steps:
●​ Get or derive user name, password for authentication from the subscriber access request
information. How the subscriber authentication credentials are obtained depends on the access
method.
○​ For PPPoE access, the subscriber’s username and password are carried in the PPPoE
discovery packet from the subscriber’s device to the vBNG router
○​ For IPoE access, the subscriber’s username and password have to be derived from its
DHCP discovery packets such as MAC address or what is carrier in option 82 strings.
 ○​ For any access methods, the vBNG router can also generate username and passwords
from the subscribers access circuit information such as VLANs, interfaces, MACs, [Link]
will discuss more on subscriber credentials later in this section.
●​ Get or derive domain name from the subscriber access request information (e.g. pppoe initiation
or dhcp discovery packets etc) or locally configured values.
●​ Use the username and password combo to compare against either locally created records or
records in a Radius database and decide if the subscribers should be authenticated or not. The
manner how this compassion should be performed is defined in the domain definition. See
section below for more information on access domain definition.
●​ If the subscriber is authenticated, the vBNG router will enter an authorization process during
which the router will allocate an IP and possibly other resources such as QoS plan etc to the
subscriber. If the authorization process is also successfully completed, the vBNG router will
create a user session on the vBNG router.
●​ If an online process fails either at the authentication or authorization stages, the vBNG router will
create an online fail record with perceived fail reason. You can access this failed record log with
the command “show vbras online-fail-record”

Understand Subscriber Access Authentication Credentials

User credentials (user name, password) are what is needed for user authentication. With Radius
authentication, the vBNG will always send the user name and password to the Radius server for
authentication. What is sent as user name and password to Radius comes from subscriber’s access
initiation or discovery packets. How the user credentials are extracted and formatted to send to
Radius depends on the access method and how formatting is configured.

Subscriber Access Credentials for PPPoE

For PPPoE, the username and password always comes from the subscriber’s PPPoE initiation
packets. The vBNG router will extract the username and password from the PPPoE initiation packet
and use them as the credential to check against stored records either locally or from Radius to
determine if the subscriber should be authenticated or not.

NOTE: The user name field in the PPPoE discovery packet inherently can carry both username and
domain name in the general format of “[user name][domain delimiter][domain]” (e.g.
JohnSmith@[Link]). Which part of the string is actually used as the username for
authentication is configurable in the subscriber’s authentication template under the key value
“user-name-format”

Subscriber Access Credentials for IPoE

For IPoE, the user name and password are not explicitly carried in DHCP discovery packets. The
vBNG will derive username, password, and access domain information from various rules that define
the mappings between username/password/domain to the various strings in the subscriber’s DHCP
discovery packets. These mapping rules are defined under the IPoE templates. Please refer to the
IPoE configuration application note for more details.
Understand Subscriber Access Domain

User access behavior is largely determined by access domain defined for the user or access
interface. Access domain will define properties such as

●​ Authentication template: this will define how the user is going to be authenticated such as none,
local, or radius, etc.
●​ Authorization template: this will define how the user is going to be authorized with properties such
as QoS, ACL, NAT etc.
●​ Accounting template: this will define how user’s online accounting records are going to be
generated and sent..
●​ vgi definition: this defines the user's access gateway.
●​ IP Pools: this will define IP V4 and V6 Pools for subscribers.
●​ Other user access behaviors such as user routes, authentication fail behaviors, etc .

User online process has two stages: authentication and authorization. A user has to be able to find its
associated domain during each of these two stages. These two stages can use the same domain or
they can use different domains. During the authentication stage, the user has to be able to find how it
is going to be authenticated. Therefore, the associated domain during the authentication stage must
have an authentication template defined. After successful authentication, the online process enters
the authorization stage, the same domain used during authentication can be used for authorization, or
another domain for authorization can be associated with the user via Radius authentication reply
message or local-subscriber domain specification. It is obvious that the only situations where
authorization domain could be different from the authentication domain are when Radius
authentication or local-subscriber management is used.

Although there is only one way that the authorization domain can be determined when different for
authentication domain (i.e. by Radius reply message), there are many ways an authentication domain
can be specified to accommodate the various ways a user’s online authentication process can be
handled by ISPs. How an authentication domain is specified depends on the access method such as
PPPoE, IPoE, and others.

Access domain specification for PPPoE

For pppoe, subscriber’s authentication domain specification can come from two places:

1.​ From subscriber’s PPPoE PADI packets: pppoe initiation (PADI) packet coming to vBNG already
carries username and password. vBNG will use the user name and password for authentication.
For example, if the user name coming in is of the format “username@domain”, vBNG will treat
the string after the “@” sign as the access domain associated with the user assuming the
domain-name-delimiter is set to “@” under the config -> bras in the router
configuration. If the domain can not be extracted based on the domain-name-delimiter
configured, the vBNG router will treat the whole username string as the username and use the
default domain value set in the PPPoX template as the access domain. For example, if the user
name is ”johnSmith@[Link]” and the domain-name-delimiter is set to “#” under
the config -> bras in the router configuration, the subscriber’s username will then be set to
johnSmith@[Link] instead of johnSmith.
2.​ From the default-domain specification in the PPPoE template definition: See PPPoE
configuration application note for PPPoE template definition.

The diagram below shows these two methods by which a PPPoE subscriber can find its access
domain definition.

NOTE: Method 1 has higher precedence than method 2. If the domain name is carried as part of the
user name in the PADI packet,a domain matching that domain name must be configured on the
vBNG. Otherwise, the subscriber won’t be able to be authenticated. The domain specified as the
default-domain in PPPoE template takes effect only if the user name in PADI packet does not carry
domain name.

Access domain specification for IPoE

As mentioned above, unlike PPPoE, IPoE connection initiation (DHCP discovery packet) does not
explicitly come in with username and password. Instead, DHCP discovery packets come in with user
ID (MAC) and possibly other DHCP option strings. netElastic’s vBNG offers flexible ways to
determine which access domain the IPoE user belongs to from the information carried in the DHCP
discovery packets. This diagram shows how the access domain is determined for IPoE access
through the ipoe-template configuration. For more detailed information on IPoE template definition,
please refer to the IPoE configuration application note.
 Domain specification summary

User online process has two stages, authentication and authorization. A domain has to be
associated with each stage. The same domain can be used for both authentication and authorization.
Domains have to be predefined in configuration and one can define as many domains as needed.
Domains can be specified dynamically or statically in the router’s running configuration .

●​ Statically configured:
○​ PPPoE authentication/authorization domain: specified as default-domain in PPPoX
template.
○​ IPoE authentication/authorization domain: specified as pre-domain in bras ->
vci-configuration.
●​ Dynamically specified:
○​ PPPoE authentication domain: specified as part of the username (the string after the
domain delimiter)
○​ IPoE authentication domain: various ways for IPoE as illustrated in the above diagram
○​ PPPoE and IPoE authorization domain: specified by radius the authentication reply or
COA messages

Subscriber Access Configuration Flow - Component by Component

As discussed above, the subscriber’s online access flow has two stages: authentication, authorization.
The behaviors of these two stages are defined in the user’s authentication and authorization templates
respectively . If the user’s online process is successful, its accounting reporting behavior is defined in its
accounting template.
These templates come into the domain definition which feeds into the PPPoX template and IPoE template
configurations for PPPoE and IPoE access respectively. Finally we enable PPPoE/IPoE access on
selected interfaces by binding PPPoX template and IPoE template to those interfaces through configuring
bras -> vci-configuration.

Access Configuration Flow Hierarchy

The access configuration is hierarchical. The following diagram shows a typical statically mapped
(domain statically mapped to user) configuration flow for IPoE access.

Here are the access configuration steps.

1.​ Identify the access interfaces and configure them accordingly. For example, if the access is
with VLANs you need to create the VLAN interfaces first. If the access needs to be on an
LACP interface with VLAN, you need to create the access trunk interface and create VLAN sub
interfaces off it. Please refer to interface configuration for more details on how to configure
interfaces.
2.​ Configure IPv4 pool from which subscribers are going to get an IPs
3.​ Optionally Configure IPv6 pool if running dual stack.
4.​ Configure VGI interfaces based on the IP pool configurations. Please refer to interface
configuration on how to create/configure VGI Interfaces
5.​ Optionally create QoS profile for rate control, priority queues, routing policies etc. Please refer
to User QoS for more details on user QoS profile creation.
6.​ Optionally create radius server groups if using radius for authentication/authorization.
7.​ Create a user access authentication template where you can bind user’s applicable
authentication radius servers.
8.​ Create a user access authorization template where you can bind user’s applicable QoS
profiles.
9.​ Optionally create a user access accounting template.
10.​ Create a user access domain where you will bind at least the following.
a.​ User’s IP pools.
b.​ User’s VGI interfaces.
c.​ User’ authentication template
 d.​ User’s authorization template.
11.​ For PPPoE access, create a PPPoX template where you set the default-domain to be the one
defined above. For IPoE access, create an IPoE template where you specify how the user
credentials and domain information is going to be extracted.
12.​ Add the access interfaces to the bras -> vci-configuration where you bind PPPoX and
IPoE templates defined above. This is where you also specify the pre-domain for IPoE
access.

For a complete configuration example, please refer to the configuration example for a typical BNG
use case.

Next, we will explain each of these steps in details

Authentication Template Configuration

Subscriber’s authentication behavior is defined by its authentication template where you can specify
no authentication, local authentication, and radius authentication. A typical configuration of the
authentication template with no authentication is shown below.
bras
authentication no_authentication
authentication-type ​ none
user-name-format ​ strip-domain
nas-port-format ​ class1
called-station-id-format​ class1
nas-port-id-format class1
calling-station-id-format class1
invalid-vlan-tag ​ 0
exit
exit

The domain definition can include the following commonly used specifications.
●​ authentication-type [local/local-radius/none/radius/radius-local/radius-none]​
authentication-type defines how subscribers are going to be authenticated. For example:
local means local authentication only. local-radius means local authentication first, if it
fails, try radius authentication. Radius authentication is the most commonly used authentication
method. Please refer to the radius authentication template section for a more detailed
explanation on radius authentication template definition.
●​ radius-authentication-group [radius authentication server group]​
For radius authentication, this is where you bind the radius authentication server group
●​ user-name-format [include-domain/only-domain/strip-domain]​
The user name received on the wire from the subscriber is in general will be interpreted in the
form of “[Name][domainNameDelimiter][Domain]” where domainNameDelimiter is the
domain name delimiter defined under bras->domain-name-delimiter. (e.g
JohnSmith@myISP, where @ is domain name delimiter). If no domain name delimiter is
detected the whole string will be considered as user name. The possible settings are:
○​ include-domain - The whole string including domain will be treated as the user name.
○​ only-domain - The domain portion of the string will be treated as the user name.
 ○​ strip-domain - Only the name portion of the string will be treated as the user name.
●​ authen-fail [offline/online domainName]​
This setting defines the behavior when subscriber online attempts fail. The possible settings are:
○​ offline - subscriber will not be connected if authentication fails.
○​ online domainName - subscriber will be allowed to get online and put into a designated
authorization domain domainName if authentication fails. In the authorization domain
domainName , you can associate rate limiting rules, http redirects, etc.
●​ nas-port-format, called-station-id-format, nas-port-id-format,
calling-station-id-format​
These define the formats for those commonly used radius attributes that the vBNG router sends
to the radius server together with username and password for authentication. Please refer to the
radius accounting template section for the definition of these formats
●​ mac-format mac-delimiter [delimiter] mac-format-type [lower/upper]​
This defines the mac address format both in delimiter and in the letter cases

Authorization Template Configuration

After a user's online access is authenticated successfully, the user’s online process enters the
authorization stage where its behavior is defined by the authorization template. The authorization
template can specify where authorization instructions come from (local, radius, mixed etc). You can
also define user QoS, ACL, and nat rules under a user’s authorization template. A typical user
authorization template is shown below.
bras
authorization radiusAuthorization
authorization-type mix-radius
user-qos-profile user_qos_1000kbpsUp_5000kbpsDown
user-acl-profile user_acl_list
bind nat-domain-name myNatRule
nat-type inside
radius-nat-switch disable
framed-route [Link] 32 gatewayAddr [Link] metric 1
framed-route [Link] 32 gatewayAddr [Link] metric 1
framed-route [Link] 30 gatewayAddr [Link] metric 1
exit
exit

Some of the most commonly used options in the authorization templates are:
●​ authorization-type [local/mix-radius/none/radius]
○​ none - The router will not assign any authorization attributes to the subscriber.
○​ local - The router will only accept locally configured authorization attributes such as
QoS plans, user ACL etc.
○​ radius - The router will only accept authorization attributes from the radius server such
as framed ip, framed pool, QoS plans, user ACL etc.
○​ mix-radius - The router will accept authorization attributes from both the radius server
and locally configured attributes. Priority will be given to attributes from the radius server
if both are present. This mode is the most commonly used authorization method. Please
 refer to the radius authorization template section for a more detailed explanation on
radius authorization template definition.
●​ bind nat-domain-name [nat rule] - Set the nat rule for the subscribers under this
authorization template. This needs to be used together with the nat-type switch which needs to
be set to inside for the specified nat rule to take effect.
●​ nat-type [inside/none] - Set nat inside or none for subscribers under this authorization
template. To bind a nat rule to a subscriber, this key needs to be set to inside.
●​ radius-nat-switch [enable/disable] - Set to include nat information (public IP and ports)
in the subscriber session detail or not. If you want the smgr session detail to carry natted public
IP and port information, this switch needs to be set to enable. Keep in mind that this only applies
to SPR nat rules. ​
NOTE: If you set the radius-nat-switch switch to enable in the authorization template , the
switch “radius-origin” under the SPR nat rule associated with this authorization template also
needs to be set to enable. Otherwise, the user session will be blocked by the nat module and
won’t be able to be established.
●​ sub-car-input cir [CIR]- Set the subscriber upload rate limit by sub car method. For
example, sub-car-input cir 20000 will set the subscriber’s upload rate to
20Mbps. Optionally you can specified the full set of subcar parameters by sub-car-input cir
[CIR] pir [PIR] cbs [CBS] pbs [PBS] (e.g. sub-car-input cir 20000 pir 20000
cbs 2500000 pbs 2500000 ).
●​ sub-car-output cir [CIR]- Set the subscriber download rate limit by sub car method. For
example, sub-car-input cir 20000 will set the subscriber’s download rate
to 20Mbps. Optionally you can specified the full set of subcar parameters by sub-car-input
cir [CIR] pir [PIR] cbs [CBS] pbs [PBS] (e.g. sub-car-input cir 20000 pir
20000 cbs 2500000 pbs 2500000 ).
●​ user-acl-profile [user acl] - set the ACL profile that will be bound to the subscriber.
●​ user-qos-profile [user qos] - set the QoS profile that will be bound to the subscriber.
●​ idle interval [interval in seconds] traffic [traffic in kB] - set subscriber
idle detection criteria. If the amount of traffic of the user during the observation interval is less
than the set amount, the subscriber will be considered idle and will be cleared from the router.
●​ timeout-absolute [session timeout in seconds] - sets the subscriber session
timeout in seconds. When session times out, the subscriber will be either disconnected or
re-authenticated depending on the timeout-reauthenticate is set to disable or enable in
the user’s access domain.
●​ bind-pool - Set IPv4 address pool if you need to set an address pool in the authorization
template to overwrite the IPv4 pool defined in the users access domain.
●​ bind-addr-pool, bind-delegation-pool, bind-prefix -Set IPv6 addres pool,
delegation pool and prefix pool respectively if you need to set any of these pools in the
authorization template to overwrite the pools defined in the users access domain.
●​ framed-route [subnet prefix] gatewayAddr [Link] metric [metric] - sets
framed routes for the user.
○​ you can set as many framed-routes as you need as shown in the example above
○​ if the framed route is a subset of the subscriber’s vgi subnet, the framed routes need to
be listed as /32 individual routes as shown in the last two framed routes in the above
example.
Accounting Template Configuration
Currently the vBNG router only supports radius accounting. Please refer to the radius accounting
template section for radius accounting configuration.

Domain Template Configuration

A domain definition defines the entire user’s online behavior from IP pool, VGI gateway,
authentication, authorization, accounting, etc. Here is an example of a user’s access domain
definition.
bras
domain myDomain
bind authentication-template radiusAuthentication_netElastic
bind accounting-template radiusAccounting_netElastic
bind authorization-template myAuthorization_200m
bind-addr-pool ​ ipoe_ipv6_addr_pool
vgi ​ vgi1
domain-status ​ unlock
user-routing-distribute ​ enable
user-ipv6-routing-distribute disable
tunnel-domain ​ disable
flow-statistic ​ enable
radius-attribute qos-acl-profile no-exist-policy offline
radius-attribute qos-profile no-exist-avp online
radius-attribute subcar-unit bps
user-max-session ​ 1
quota-out offline
bind-pool 1 localPool
exit
exit

The domain definition can include the following commonly used specifications.
●​ bind authentication-template: define authentication template
●​ bind authorization-template: define authorization template
●​ bind accounting-template: define accounting template
●​ vgi: defines the associated vgi interface.
●​ bind-pool [poolIndex]: define associated IPv6 pools. You can associate up to 16 pools
under one domain.
●​ user-routing-distribute enable/disable: enable or disable 32bit IPv4 user routes
●​ user-ipv6-routing-distribute enable/disable: enable or disable IPv6 user routes
●​ radius-attribute qos-profile no-exist-avp online/offline: allow user to be
online or offline if the user’s QoS profile is not sent from radius.
●​ radius-attribute qos-acl-profile no-exist-policy online: allow user to be
online or offline if the user’s ACL profile is not sent from radius.
●​ bind-addr-pool: define association of IPv6 address pool.
●​ bind-prefix: define association of IPv6 prefix address pool.
●​ bind-delegation-pool: define association of IPv6 delegation pool.
●​ radius-attribute subcar-unit [bps/kbps]: configures the unit of subcar QoS rates
when the QoS subcar rates are specified using the RADIUS attributes
NetElastic-Input-Average-Rate and NetElastic-Output-Average-Rate.
 ●​ user-max-session [max sessions]: Configures the maximum number of allowed
sessions under the same username. For example, for IPoE access, if you want to allow only
one IP address to be assigned to a subscriber regardless of how many devices they have, you
should set this value to 1

PPPoX Template Template Configuration

For PPPoE connections, we need to define a PPPoX template and bind the above defined domain to
it and then associate the template to an access interface. For PPPoX template configuration, please
refer to the PPPoE configuration guide.

IPoE Template Template Configuration

For IPoE connections, we need to define an IPOE template and then associate the template to an
access interface with the above defined domain as pre-domain . For IPoE template configuration,
please refer to the IPoE configuration guide.

Enabling PPPoE and IPoE on Access Interfaces

Finally to enable PPPoE/IPoE services on access interfaces, we need to define interfaces under bras
-> vci-configuration to:
1.​ Bind PPPoX/IPoE templates on the access interfaces.
2.​ Specify the authentication domain under pre-domain for IPoE access.​

Here is an example of a vci-configuration where we enabled IPoE service on interface

10gei-1/1/2, and both IPoE and PPPoE services on interface 10gei-1/1/5.

bras
vci-configuration
interface gei-1/1/2
ipoe template my_ipoe
max-ipox-session 32000
max-pppox-session 32000
encapsulation ​ multi
pre-domain ​ myDomain
ip-access-type​ ipv4
exit
interface gei-1/1/5
ipoe template my_ipoe
pppox template local_pppoe
max-ipox-session 32000
max-pppox-session 32000
encapsulation ​ multi
pre-domain ​ myDomain_Radius
v6pre-domain ​ domain_pre_web
ip-access-type​ ipv4
exit
exit
exit
 Local Authentication with IPv4/v6 static IP, Mac-binding
For the local authentication use cases, in the bras section, we need to create local subscribers with
corresponding information as shown below. In addition, make sure the authentication type in the
authentication template is local.

The example is for IPoE here, but it should be similar for PPPoE. Again, for better scalability, Radius
is always recommended for this kind of use cases.

authentication local
authentication-type local
user-name-format strip-domain
nas-port-format class1
nas-port-id-format class1
calling-station-id-format class1
invalid-vlan-tag 0
exit
authorization local_10M
authorization-type local
user-qos-profile user_10M
nat-type none
radius-nat-switch disable
exit
domain ipoe_dedicated_users
bind authentication-template local
vgi vgi1
domain-status unlock
user-routing-distribute disable
tunnel-domain disable
flow-statistic enable
radius-attribute qos-acl-profile no-exist-policy offline
quota-out offline
bind-pool 1 my_ippool
exit
local-subscriber 00-10-94-00-00-02 domain ipoe_dedicated_users
bind authorization-template local_10M
ipv4-address [Link]
mac-bind 00:10:94:00:00:02
password 00-10-94-00-00-02
exit

Access Configuration by Access Types

PPPoE Access Configuration

For PPPoE access configuration, please refer to the PPPoE configuration application note.

IPoE Access Configuration

For IPoE access configuration, please refer to the IPoE configuration application note.
IPhost Configuration

Within the realm of IPoE access, although allocating IP dynamically from the vBNG router by the
DHCP process is the prevailing IP allocation scheme, there are also situations where users wish to
have static IPs and assign them to their CPE devices statically by themselves. This mode of access
to the vBNG router is called IPhost. These static (IPhost) users will put static IPs assigned to them
on their devices which are connected to the vBNG router. At ARP resolution time, the vBNG will
acknowledge the presence of these users, collect user credentials, authenticate (if so configured),
authorize with appropriate resources, and create and maintain a live user session if all are
successfully done.

IPhost is a special case of IPoE. They share most of the same configuration in terms of AAA, ippool,
vgi, vgi-configuration, domain, and vci-configuration. IPhost access does, however, require some
special configuration provisions. The following IPhost specific configurations need to be added to
normal IPoE configurations.

Reserve IPhost IPs in the IP pool configuration.

The following sample shows an IP pool configuration with IPhost reserved IP highlighted in red.

ippool group IPoE-IPhost

gateway-ip [Link] gateway-mask [Link]
lease-time 3600
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
reserved-section reserved-start-ip [Link] reserved-end-ip [Link]
reserved-section reserved-start-ip [Link] reserved-end-ip [Link]
exit

Add IPhost users’ IPs in their corresponding vgi-configuration.

The following sample shows a vgi-configuration with IPhost user entries highlighted in red.

bras
vgi-configuration
interface vgi5
ip-host [Link] [Link] eth-trunk3.203 user-name testUser
domain-name host password 123 dot1q 203
ip-host [Link] [Link] eth-trunk3.205 domain-name host qinq
external-vlan 45 internal-vlan 205
ip-host [Link] [Link] eth-trunk3.207 domain-name hostqinqinq
outmost-vlan 34 preoutmost-vlan 23 inmost-vlan 207
 exit
exit

Notes about ip-host configuration:

●​ The access interface associated with the ip-host configuration has to be already configured
and committed under bras -> vci-configuration before you can commit any ip-host
configuration. Therefore it is important to configure the ip-host access interfaces under bras
-> vci-configuration first before configuring ip-host.
●​ You can enter either a singular IP entry or an IP range entry for a group of iphost users.
●​ You can optionally specify a user name and password under the keys “user-name” and
“password” for one IP user or group of IP users as shown in one of the ip-host
statements in the example. When username or/and password are not specified, the
username and password used for authentication will be generated based on the default
username and password configured under the vci-configured. More username/password
options for authentication are explained below.
●​ You have to specify the interface from which the iphost access requests come in.
●​ Optionally, you can specify a domain name by the key “domain-name”. This is the domain
by which iphost access authentication behavior is defined. If an authorization template is
referenced in the domain specified under “domain-name”. That domain will also be the
iphost user’s authorization domain. If no domain name is specified, the domain defined
under the key pre-domain in the subscriber’s vci-interface (bras ->
vci-configuration -> interface xxx) will be used.
●​ Optionally you can use the key “author-temp-name” to specify an authorization template
for the iphost user. Please note that the specification of the parameters “domain-name” and
“author-temp-name” are mutually exclusive. You can only specify one of them, but not
both at the same time for the iphost subscriber. When an authorization template configured
under “author-temp-name” is set, it will override the authorization template referenced in
the user's access domain defined under the key pre-domain in the subscriber’s vci-interface
(bras -> vci-configuration -> interface xxx).
●​ If IPHost subscribers connect through a sub-interface with dot1Q, QinQ, or QinQinQ VLAN
tags, VLAN parameter configuration may be required depending on the router version and the
intended behavior.
○​ For router versions prior to B4P32, it is critical to configure VLAN parameters to match
the VLAN tags of the IPHost users if their connections are VLAN-tagged, as shown in the
example above. If VLAN parameters are not configured, the router will only accept
untagged IPHost connections, and all tagged connections will be denied.
○​ For router versions B4P32 and later, VLAN parameter configuration is optional for tagged
traffic. If VLAN parameters are not configured, the IPHost interface will accept all IPHost
connections without checking VLAN tags. If VLAN parameters are configured, the IPHost
interface will only accept connections with VLAN IDs that match the configured values.
●​ For an iphost with web authentication (portal flow), it is imperative to specify the “web”
authentication method (highlighted in red in the example below) AND to bind the iphost user’s
domain to the pre-web domain in the iphost configuration. The user-name and password
settings are not necessary. Here is an example of iphost web portal flow configuration. ​
ip-host [Link] [Link] gei-1/1/2 domain-name domain_pre_web web​
For detailed information about portal authentication flow, please refer to the portal
authentication configuration guide.
Notes about ip-host username and passwords:
There are situations where you would need iphost users go through an individualized authentication
and authorization process just like normal IPoE users either by their MAC, IP, or other access
characteristics. vBNG provides quite a bit of flexibility in formulating access control user names and
passwords from the subscriber access characteristics which include MAC, IP, vlan, etc. Here are the
basic rules:
●​ If username and password are specified in the ip-host configuration under the
bras->vgi-configuration->interface vgi[x] as shown in the above example, the
configured username and password will take precedence over other configurations as the iphost
user’s username and password for authentication.
●​ If NO username and password are specified in the ip-host configuration under the
bras->vgi-configuration->interface vgi[x], but default-user-name and
default-user-password are configured under bras->vci-configuration->interface
[xxxx] with defined username and password templates, the vBNG router will use the username
and password format templates defined under bras->default-user-name template
[templateName] and default-user-password template [templateName]. Here is an
example of using the subscribers’ MAC address as username and password.
!define a user name template where you specify to use mac as user name
bras
default-user-name template iphost-user-name
type [ mac ] format %s
exit
exit

!define a password template where you specify to use mac as user password
bras
default-user-password template iphost-user-password
type [ mac ] format %s
exit
exit

!under the relevant interface under vci-configuration, use the key ​

! "default-user-name" to specify the defined user name template for iphost
! likewise for user password specification​
bras
vci-configuration
interface gei-1/1/4
default-user-name ​iphost-user-name
default-user-password iphost-user-password
exit
exit
exit

●​ If no username and password are specified in the ip-host configuration under the
bras->vgi-configuration->interface vgi[x]AND no default-user-name and
default-user-password are configured under bras->vci-configuration->interface
[xxxx], then the IPhost users does not carry username or password.

Other related configurations such as authentication, authorization, domain, access template, and vci
remain the same as their corresponding IPoE configurations.

To display IPhost access status, use the show smgr-session detail user iphost command.
domain# show smgr-session detail user iphost
smgr-session detail user iphost
info
mac-address 00:20:03:00:00:01
ip-access-type ipv4
auth-type none
auth-status accept
user-name ~
domain-name host
author-domain host
create-time "2019-09-30 13:15:13"
online-times 17
access-interface eth-trunk3.203
vlan 203/0
vgi-interface vgi5
vrf-name host
ippool-name host
ipv4-address [Link]
gateway-address [Link]
accounting-info acct-type:none
nat-info "nat-type:none nat-domain: public-ip:[Link] start-port:0 end-port:0
nat-interval:0"
family-info "family-id:0 family-qos-profile:"
policy-name "acl: qos: user-group:"
timeout "session-timeout:0(second) prepay:-(second) -(kbyte) idle-timeout:
0(second) 0(KB)"
webforce-info "webforce-flag:0 adforce-flag:0 special-acl: http-url:
advertisement-url:"
subcar-input "cbs:0(B) cir:0(kbps) pbs:0(B) pir:0(kbps)"
subcar-output "cbs:0(B) cir:0(kbps) pbs:0(B) pir:0(kbps)"
unicast-traffic "update-time:2019-09-30 13:15:28.964 up-stream:0(byte) packets:0
down-stream:0(byte) packets:0"
mru 0

Disconnect ip-host users

Iphost users can be disconnected either from radius by DMCOA message or by user initiated
disconnection. With user initiates user disconnect, the BNG router will clear the user session once
the iphost user’s ARP entry times out on the BNG router. This time it takes to clear an iphost user
session can be anywhere from seconds to minutes depending on the ARP timeout settings. There
are two ways to control the time from user disconnection to clearing the user session:
●​ set arp timeout timer by setting “arp expire-time [timer]”, where timer is the ARP
timeout value in seconds.
●​ add user detect on the interface from which the iphost user connects to the BNG router. This
is configured under “bras -> vci-configuration -> interface [access
interface] -> user-detect retransmit [retransmit times] interval
[interval] [no-datacheck]”. There are two options for configuring user-detect:
○​ user-detect retransmit [retransmit times] interval [interval]​
Without the no-datacheck option, the BNG will flag the subscriber to be disconnected
as soon as the arp miss tolerance set by the “user-detect retransmit
[retransmit times] interval [interval]” is violated. However the BNG won’t
immediately disconnect the user. It will wait until the user’s next accounting update
interval to see if the user’s data usage is more than what it was from the last accounting
 interval. If the user’s data usage is not larger than that from the previous accounting
interval, the user will be disconnected. Otherwise, the user will be kept on even if the arp
miss tolerance has been violated. With this configuration, even if the subscriber is
legitimately disconnected from the BNG, the user won’t be immediately disconnected. It
will take one accounting update interval for the user to be disconnected even when arp
miss detection has indicated that the user should be disconnected much earlier.
○​ user-detect retransmit [retransmit times] interval [interval]
no-datacheck​
With the no-datacheck option set, the BNG will disconnect the subscriber as soon as
the arp miss tolerance set by the “user-detect retransmit [retransmit times]
interval [interval]” is violated. For example setting “user-detect
retransmit 3 interval 30 no-datacheck”, means the user will be disconnected
from the router if the router could not get any arp reply from the user 3 times in a row for
ARP probes sent once every 30 seconds.

Finally, It is important to note the difference between IPhost and framed IP. In both cases, the user’s
IP is statically assigned. The differences are:
●​ The IPs for IPhost users are assigned by the subscribers themselves. The vBNG learns their
IP through ARP. Framed IPs are assigned by the vBNG either dynamically assigned through
Radius or statically configured on the vBNG for local subscribers as referenced in section 7.6
●​ IPhost is part of IPoE access scheme and does not apply to PPPoE. Framed IP assignment
applies to both PPPoE and IPoE

Leased Line Configuration

The leased line service is an access method where a subscriber can get a subnet from the vBNG
router. All the IPs within the subnet belong to the same user. The vBNG router will create one user
session for this leased subnet. All IPs within the subnet will be subject to the same user session
management such as user name, password, domain, qos, nat, etc. The leased line service is always
tied to a particular interface. The configuration of the leased line service consists of the following:

●​ Identify an interface from which the lease line service is going to be provided. Assign the
interface with a gateway IP which will be the gateway of the leased line IPs
●​ Under bras->leased-line-configuration, add the interface from which the leased line
service is provided. Under each interface, create the user name, password, and domain. These
are the credentials mapped to the subscriber’s leased line services. Committing the configuration
will immediately trigger authentication with these credentials either locally or through radius.

Here is a configuration example.

! This is the lease line access interface. configure leased line gateway
here.
interface 10gei-1/1/11
ipv4 address [Link] 24
exit

! set leased line subscriber’s username, domain, and password

 ! and tie them to the corresponding leased line interface
bras
leased-line-configuration
interface 10gei-1/1/11
user-name userName domain-name userDomain password netElastic
! authentication behavior should be define in the userDomain
exit
exit
exit

Use the command show smgr-session all to display user succession status. Leased line user
sessions will be displayed as shown in the following example.

Lease line user sessions are created as soon as the configuration is committed. To clear/reset a
lease line session you need to remove and add the user-name configuration by following these steps
1.​ remove the user-name configuration under “config -> bras ->
leased-line-configuration -> interface xxx -> no user-name “ and then
commit
2.​ add the user-name configuration line back in (e.g. config -> bras ->
leased-line-configuration -> interface xxx -> user-name userName
domain-name userDomain password myPassword) and then commit.

L3 Mhox Access Configuration.

The access methods discussed above (IPoE, PPPoE, Iphost, etc) all require the client devices to
have direct L2 connections to the BNG router. However, there are situations where the incoming
traffic is already L3 traffic and the BNG router is expected to just perform services such as subscriber
rate control and CGNAT based on IP subnets. The BNG router supports this kind of use case with
the mhox access configuration. With mhox access, although the most common authentication
method is “none” as the subscriber authentication is likely already done prior to the BNG router, our
BNG router does optionally support circuit map and web authentication for mhox access. The mhox
access configuration generally involves the following steps.
●​ Create the access interface from which the mhox traffic comes in. The interface will be set
with the access subnet’s gateway address. The switch “nat inside” needs to be set on
the interface if the incoming traffic needs to go through NAT.
●​ Create QoS profiles that you would like to associate with mhox subscribers. For example, if
you want the subnet [Link]/24 to have 50Mbps package and subnet [Link]/24 to
have 100Mbps packages, you will need to create the corresponding QoS profiles first.
Optionally you can control subscriber’s rate by simply adding CIR to the user’s authorization
template as described here. In that case, you don’t need to configure any QoS profiles.
●​ Create CGNAT rules for the mbox subscribers if their traffic needs to be natted.
●​ Create authorization templates that bind the QoS profiles and NAT rules defined above.
Optionally you can also directly set subscriber’s CIR in the authorization template (follow this
link for setting CIR in authorization template). You will need to create different authorization
 templates for different subnets if their expected behaviors(such as different QoS plans,
different NAT rules, etc.) are different.
●​ Optionally create an authentication domain if mhox access needs to be authenticated. Keep
in mind that mhox access only supports circuit map and web authentication.
●​ Create domains that bind the authorization and authentication templates defined above. You
will need to create different domains for different subnets if their expected behaviors are
different.
●​ Create mhox configuration (bras -> l3-access-configuration) for each access
interface from which mhox access comes in. For each interface, you will specify its
associated domain, authentication type, IP range, and vlan information.
●​ All other configurations such as routing will be the same as with other types of access
methods.​

Next we will use an example to show all relevant configurations. In this example, we will assume
●​ We have two access interfaces 10gei-1/1/0.100 and 10ge-1/1/0.2000.
●​ Interface 10gei-1/1/0.100 serves subnet [Link]/24. It has dot1q tag 100 and gateway
IP [Link]/24
●​ Interface 10gei-1/1/0.2000 serves subnet [Link]/24. It has QinQ tag 100, 2000 and
gateway IP [Link]/24
●​ Subnet [Link]/24 is limited to symmetrical 50Mbps and Subnet [Link]/24 is limited
to symmetrical 100Mbps
●​ Access through these two interfaces does not need authentication and going through CGNAT.

Here are the related configurations

! create mhox access interfaces and assign gateway IPs
interface 10gei-1/1/0.100
ipv4 address [Link] 24
dot1q 100
exit
interface 10gei-1/1/0.2000
ipv4 address [Link] 24
qinq internal 100 external 2000
exit

! create two QoS plans

behavior CAR_50M
item 1
car cir 50000 pir 50000 cbs 6250000 pbs 6250000
exit
exit
behavior CAR_100M
item 1
car cir 100000 pir 100000 cbs 12500000 pbs 12500000
exit
exit
class_map all_traffic match-way match-any
match all
exit
policy CAR_50M_Policy
class_map all_traffic behavior CAR_50M
exit
policy CAR_100M_Policy
class_map all_traffic behavior CAR_100M
exit
bras
user-qos-profile VLAN100-QoS
input-qos-policy CAR_50M_Policy
output-qos-policy CAR_50M_Policy
exit
exit
bras
user-qos-profile VLAN2000-QoS
input-qos-policy CAR_100M_Policy
output-qos-policy CAR_100M_Policy
exit
exit

! create authorization template and bind rate plans

bras
authorization VLAN100-Authorization
authorization-type mix-radius
user-qos-profile VLAN100-QoS
nat-type ​ none
radius-nat-switch disable
exit
authorization VLAN2000-Authorization
authorization-type mix-radius
user-qos-profile VLAN2000-QoS
nat-type ​ none
radius-nat-switch disable
exit
exit

! create corresponding domain

bras
domain VLAN100-Domain
bind authorization-template VLAN100-Authorization
domain-status ​ unlock
exit
domain VLAN2000-Domain
bind authorization-template VLAN2000-Authorization
domain-status ​ unlock
exit
exit

! configure mhox access configuration and bind interfaces to their domains

bras
l3-access-configuration
interface 10gei-1/1/0.100
pre-domain ​VLAN100-Domain
authentication-type none
ipv4-multi-host start-ip [Link] end-ip [Link] dot1q 100
exit
interface 10gei-1/1/0.2000
pre-domain ​VLAN2000-Domain
authentication-type none
ipv4-multi-host start-ip [Link] end-ip [Link] qinq external-vlan
2000 internal-vlan 100
exit
exit
exit
 As mentioned earlier, the configuration shown above assumes no authentication. Mhox access
supports circuit-map and web authentication. Here is mhox configuration if we want to switch the
authentication on the interface 10gei-1/1/0.2000 from “none” to using “cir-map”. As
illustrated in this example, as far as authentication is concerned, all IPs from the interface
10gei-1/1/0.200 will have authentication credentials username=pasword=VLAN200 and domain
VLAN2000-Domain.

bras
circuit-map 1
interface 10gei-1/1/0.2000 qinq external 2000 to 2000 internal 100 to 100
username VLAN2000 domain VLAN2000-Domain password VLAN2000
exit
exit

bras
l3-access-configuration
interface 10gei-1/1/0.2000
pre-domain ​VLAN2000-Domain
authentication-type cir-map
ipv4-multi-host start-ip [Link] end-ip [Link] qinq external-vlan
2000 internal-vlan 100
exit
exit
exit

To check mhox access status, use the command “show smgr-session all user mhox”

Keep in mind the mhox user sessions are created when the mhox configurations are committed. For
example, if you have 250 IPs defined under the mhox configuration, you will see 250 mhox user
sessions created as soon as the configuration is committed. If you delete the mhox user sessions,
you need to delete the mhox configuration and add it back in to trigger the mhox user session
creation again.

L3 Flow Access Configuration.

Similar to MHOX access described in the previous section, L3 flow access is designed to trigger user
sessions on the BNG based on Layer 3 IP flow activity. The difference between MHOX access and L3
flow access is that user sessions in L3 flow access are created dynamically—based on the source IP
of incoming traffic—whereas user sessions for MHOX are created statically.

For L3 flow access, the default username and password are set to the string representation of the
IPv4 source address. When the router receives the first packet of an L3 flow on an interface
configured for L3 flow access, it triggers a user online process using the source IP address of the flow
as both the username and password.

The L3 flow access configuration typically involves the following steps.

●​ Create the access interface from which the L3 traffic will enter. Assign an IPv4 address to the
interface. If the incoming traffic needs to go through NAT, enable the nat inside switch on
the interface.
 ●​ Create IP pools that mirror the source IP ranges of the Layer 3 flows entering the router.
Although the router is not allocating IPs from these pools, the pool definitions are required so
the router can track the IP addresses of online subscribers and prevent issues such as
duplicate IPs. You can configure a /32 gateway in the IP pool configuration.
●​ Create QoS profiles and CGNAT rules in the same manner as you would for other access
methods
●​ Create an authorization template that binds the QoS profiles and NAT rules defined in the
previous step.
●​ Create an authentication template where you can specify how L3 flow access should be
authenticated (e.g., no authentication or RADIUS authentication).
●​ Create domains that bind the authorization and authentication templates, and ippools defined
above
●​ Create L3 flow configuration under bras -> l3-flow-access-configuration and add
the interfaces from which L3 flows will enter. Under each interface, specify the user’s access
domain and VGI interface.
●​ Configure all other necessary settings (such as routing) as you would for other types of
access methods.

Below is a sample configuration

! define L3 flow access interface

interface 10gei-1/1/4
ipv4 address [Link] 24
exit

! define pool 1
ippool group l3flowaccess-pool1
gateway-ip [Link] gateway-mask [Link]
frame-pool disable
lease-time 3600
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit

! define pool 2
ippool group l3flowaccess-pool2
gateway-ip [Link] gateway-mask [Link]
frame-pool disable
lease-time 3600
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit
 ! create authentication template
bras
authentication myAuthentication
authentication-type ​ none
user-name-format ​ strip-domain
exit
exit

! create authorization template

bras
authorization myAuthorization
authorization-type mix-radius
nat-type none
radius-nat-switch disable
exit
exit

! create the L3 flow access domain

bras
domain myL3AccessDomain
bind authentication-template myAuthentication
bind authorization-template myAuthorization
domain-status unlock
bind-pool 1 l3flowaccess-pool1
bind-pool 2 l3flowaccess-pool2
exit
exit

! create L3 flow access configuration

bras
l3-flow-access-configuration
interface 10gei-1/1/4
access-domain myL3AccessDomain
exit
exit
exit

Access over VxLAN Configuration.

The netElastic router can be configured either as a vTAP access point to encapsulate L2 traffic into
VXLAN and send it over a VXLAN tunnel, or as a vTAP termination point to decapsulate VXLAN
traffic and map the encapsulated L2 frames to an L2 access bridge interface. The router can then
treat this bridge interface as a regular L2 VCI interface, from which vBNG access services such as
IPoE and PPPoE can be enabled.
The following example shows how to configure the router as a vTAP access point and termination
point for the following scenario.
●​ Two routers are connected via L3 interfaces. The feeding router (Router A) has IP
[Link]/24 on interface 10gei-1/1/1 with VLAN 1114. The termination router (Router B)
has IP [Link]/24 on interface 10gei-1/1/0 with VLAN 1114. We will set up a VXLAN tunnel
between Router A (interface 10gei-1/1/1.1114) and Router B (interface 10gei-1/1/0.1114).
●​ Router A has two L2 VLANs (VLAN 10 and VLAN 20) on which PPPoE and IPoE services will be
enabled. These services will be transported over the VXLAN tunnel to Router B, where the
PPPoE and IPoE sessions will be terminated and BNG subscriber services will be established.
●​ Router A will be configured as a vTAP access point to transport L2 services to Router B.
●​ Router B will be configured as a vTAP termination point and will provide BNG services for the
PPPoE and IPoE connections transported from Router A

Configure VXLAN as a vTAP access point.

! L2 access interface whose traffic is going to be set over vxlan

interface 10gei-1/1/0.10
description L2-IPoE-Access-Interface
dot1q 10
exit

! L2 access interface whose traffic is going to be set over vxlan

interface 10gei-1/1/0.20
description L2-IPoE-Access-Interface
dot1q 20
exit

! network interface on which vxlan tunnel to be established

interface 10gei-1/1/1.1114
description L3-vxlan-tunnel-interface
ipv4 address [Link] 24
dot1q 1114
exit

! create vxlan tunnel. tunnel ID is the number after the keyword

vxlan-tunnel
interface vxlan-tunnel1
tunnel source [Link]
tunnel destination [Link]
exit

! create vxlan service instance and bind to the L2 access interface

service instance 1
bind port 10gei-1/1/0.10 vlan 10
exit

! create vxlan service instance and bind to the L2 access interface

service instance 2
bind port 10gei-1/1/0.20 vlan 20
exit

! create vfi and bind vxland service instance and tunnel id

 ! to an unique vxlan_id
vfi vxlan-session1
vxlan_id 100
service_instance 1
tunnel_id 1
exit

! create vfi and bind vxland service instance and tunnel id

! to an unique vxlan_id
vfi vxlan-session2
vxlan_id 200
service_instance 2
tunnel_id 1
exit

Configure VXLAN as a vTAP termination point for IPoE/PPPoE access.

! network interface on which vxlan tunnel to be established

interface 10gei-1/1/0.1114
description To_VBRAS104.235_eth2.1114
ipv4 address [Link] 24
dot1q 1114
exit

! create vxlan tunnel. tunnel ID is the number after the keyword

vxlan-tunnel
interface vxlan-tunnel1
tunnel source [Link]
tunnel destination [Link]
exit

! create vfi instance and bind corresponding vxlan_id and tunnel id

vfi vxlan-session1
vxlan_id 100
tunnel_id 1
exit

! create vfi instance and bind corresponding vxlan_id and tunnel id

vfi vxlan-session2
vxlan_id 200
tunnel_id 1
exit

! create bridge domain (bd) interface and bind it to the vxlan_id

! bd interface needs to have the keyword bd followed by an integer
interface bd1
bind vni 100
exit

! create bridge domain (bd) interface and bind it to the vxlan_id

 ! bd interface needs to have the keyword bd followed by an integer
interface bd2
bind vni 200
exit

! The Rest of the Configurations:

! Treat the BD interfaces as normal L2 VCI interfaces and configure
! the remaining PPPoE or IPoE settings through these BD interfaces
! the same way you would for PPPoE and IPoE access, as described
! in the PPPoE and IPoE access methods.

PPPoE over L2TP (LAC/LNS) Configuration.

Please refer to this application note for PPPoE access configuration by L2TP

VPWS Pseudowire Headend (PWHE) Configuration

Please refer to this application note for access configuration by VPWS

Inter-subscriber Communications
By default, subscribers won’t be able to communicate with each other for security reasons. If you need to
enable communication among subscribers, you need to
●​ enable 32 bit user routes
●​ setup arp proxy on the access (VCI) interfaces

Enable user routes

To enable the 32 bit user route, you need to set “” in the user’s access domain like what is highlighted
in the following sample domain configuration.
bras
domain myDomain
bind authentication-template radiusAuthentication_netElastic​
bind authorization-template myAuthorization
vgi ​ vgi1
domain-status ​ unlock
user-routing-distribute ​ enable
user-ipv6-routing-distribute disable
radius-attribute qos-acl-profile no-exist-policy offline
radius-attribute qos-profile no-exist-avp online
bind-pool 1 localPool
exit
exit
 Setup ARP Proxy
If a subscriber wants to communicate with another subscriber in the same subnet, the subscriber will
try to resolve the ARP of the other subscriber since they are in the same subnet. Since the
subscriber’s VCI interface is the interface on which ARP is received, but which does not have any IP
configured. We need to enable ARP proxy on the subscriber’s VCI interface so any ARP to the IP
address within the subnet can be resolved to the VCI interface. Here is an example of ARP proxy
configuration for two VCI interfaces.
arp proxy​
interface eth-trunk1.100​
interface eth-trunk1.200​
exit

Block User Access Based on Uplink Availability.

If the BNG router’s uplink has connectivity issues and you want to block the subscriber access to the
router when it happens. You can do so by
1.​ Configure a ping detect group if a ping test is used to test IP reachability. This is optional. Ping
detect group does not need to be configured if ping test is not used for testing reachability.
2.​ Configure tracker events such as interface protocol state or ping detect for validating the
reachability to the next hop.
3.​ Configure a tracker group to group the tracker events defined in step 1. Any of the events in one
tracker group will flag the tracker group to be at fault.
4.​ Configure access-track to block access when an associated tracker group event happens.

The following is an configuration example in which all user access will the blocked if the wan interface
10gei-1/1/1 is down OR ping can not reach the router’s next hop [Link] through the interface
10gei-1/1/1, or ping can not reach the radius server [Link] through the interface 10gei-1/1/0.200.

! define a ping detect group called pingDetect

detect-group pingDetect
option ​ or ! the logic relationship among detect-list items
test-type ​ icmp-echo ! test mode echo/jitter
retry-count ​ 2 ! failure will declare after retry-count
loop-time ​ 15 ! ping test round trip max delay limit
timeout ​ 2 ! single ping test failure timeout before retry
sampling-period 30 ! how often the ping test is conducted.
detect-list 1 [Link] interface 10gei-1/1/1 ! next hop test
detect-list 2 [Link] interface 10gei-1/1/0.200 ! radius test
exit

! define tracker events and then tracker group

tracker
track-group wanReachability ! define tracker group and add events
track wanInfState
track wanPingDetect
 exit
track wanInfState interface protocol-status 10gei-1/1/1 ! tracker event
track wanPingDetect ping-detect group pingDetect ! tracker event
exit

! block subscriber access when tracker group event happens

bras
access-track pppoe bind track-group wanReachability
access-track all bind track-group wanReachability
exit

Access Track behavior when tracker state changes:

●​ When the tracker state goes down:
○​ Subsequent access requests of the access-track type will be rejected.
○​ Subscribers that are currently online will be placed on a timeout chain and taken offline in
scheduled batches at a rate of approximately 1,000 subscribers per second.
●​ When the tracker state comes back up:
○​ New access requests of the access-track type will be allowed and processed.
○​ Subscribers that were placed on the timeout chain during the previous tracker-down
event, but have not yet been taken offline, will be removed from the chain and will remain
online.

Check User Access Status

After the user access configuration is complete and subscribers are connected to the vBNG router, there
should be user sessions on the vBNG router if the subscriber connections are successful. The following
commands can be used to display user session information:
●​ show smgr-session summary​
display user session summary by access types, interfaces, domains
●​ show smgr-session all​
list all user sessions in a tabular format.
●​ show smgr-session detail​
shows all active sessions in detailed format record by record. When a significant number of users
are online, the list can be too long to display. You can selectively display user records by applying
filters as shown in the next command.
●​ show smgr-session detail by-xxx​
displays user sessions in detailed format for users meeting certain filtering criteria. The “xxx” in
the command represents a myriad of options such as access domain, accounting id, authorization
domain, dot1q, ipv4 address, qinq, qinqinq, user name, etc.
●​ show subscriber-traffic-rate by xxx​
display a user’s connection rate by various user handles. The command format is “show
subscriber-traffic-rate by [ipv4-address, ipv6-address, mac-address,
user-name]”. Here is an example of showing user’s connection rate by its MAC address:
“show subscriber-traffic-rate by user-name e4-b9-7a-88-f1-d5”

The The user session details by default lists the following fields for the users displayed
 access-interface ​ framed-route ​policy-name ​
access-mode ​ gateway-address ​session-id ​
accounting-info ​ igmp-profile ​subcar-input ​
auth-status ​ ip-access-type ​subcar-output ​
auth-type ​ ippool-name ​tcp-adjust-mss ​
author-domain ​ ippoolv6-name ​timeout ​
classmap-input ​ ipv4-address ​unicast-traffic ​
classmap-output ​ ipv6-address ​unicast-traffic-web
create-time ​ l2tp-info ​user-access-type ​
dns-v4 ​ lawful-intercept ​user-index ​
dns-v6 ​ mac-address ​user-name ​
domain-name ​ mru ​vgi-interface ​
dropped-traffic ​ multicast-traffic ​vlan ​
duid ​ multicast-traffic-web ​vrf-name ​
family-info ​ nat-info ​webforce-info ​
framed-ipv6-route ​ online-time ​

You can pick and choose any one or more of the fields to display. To select more than one fields, use the |
operator with select. Here is an example
domain# show smgr-session detail user info user-name | select info auth-status |
select info mac-address
USER ​ AUTH
TYPE MAC ADDRESS ​ STATUS USER NAME
----------------------------------------------------
ipoe e4:b9:7a:88:f1:d5 accept e4-b9-7a-88-f1-d5
84:2b:2b:aa:86:4f accept 84-2b-2b-aa-86-4f

User Access Troubleshooting

Here are some of the commonly used commands and practices for troubleshooting user access related
issues.

Check Online Fail Record Log

The vBNG router keeps track of user access fail records with diagnosed failed reasons. Use the
command “show vbras online-fail-record” to display the latest online fail record log. To
clear the online fail records, use the command “clear-vbras-online-fail-record”. ​
​
NOTE: The maximum number of fail record history length can be set under bras ->
subscriber-manage -> session online-fail-record. The maximum number of records is
32K.

Check Abnormal Offline Record Log

vBNG keeps track of user abnormal offline records with diagnosed abnormal offline reasons. Use the
command “show vbras abnormal-offline-record” to display the latest abnormal offline
record log. To clear the abnormal offline records, use the command
“clear-vbras-abnormal-offline-record”
 NOTE: The maximum number of fail record history length can be set under bras ->
subscriber-manage -> session abnormal-offline-record. The maximum number of
records is 32K.

For more detailed vBNG router troubleshooting information, please refer to the vBNG Router
Troubleshooting Guide.

Radius Integration and AAA

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized
Authentication, Authorization, and Accounting management for users who connect and use a network
service. Since vBNG works very closely with the Radius server for user access management. We will
describe how the vBNG router shall be integrated with an external Radius server and how vBNG
operations with Radius server for authentication, authorization, and accounting (AAA).

Radius Integration
The vBNG router uses inband connections to talk to external Radius servers. It supports configuring
multiple Radius servers for redundancy and reliability. Radius integration involves the following step:
●​ On the Radius server of your billing system ​
Load netElastic Radius dictionary. netElastic dictionary can be downloaded from this link.
●​ On the vBNG router.​
Configure Radius authentication and accounting groups on the vBNG router. This will be
explained in separate sections below.

Radius Global Configurations

The following configuration example shows some of the global radius configuration options

●​ radius vendor-id 54268 : set the radius vendor-id. 54268 is netElastic’s radius vendor ID
●​ max-send-speed [messageRate ]: set the rate at which radius authentication and accounting
requests are sent to radius servers. This is needed sometimes to control the radius access
requests rates to radius servers in order not to overwhelm the radius server. The messageRate
is the number of radius request messages sent to the radius servers per second and it can be
configured with any value between 1 and 10000000.
●​ radius accounting-on enable/disable: enable or disable radius accounting.
●​ radius ping-test group: configure additional radius authentication request attributes when
running radius-ping test . see more details in the radius ping test section
●​ radius framed-route-delimiter [delimiter]: set radius framed route delimiter when
multiple framed routes are sent from radius. The default delimit is “;”

Radius Authentication
In the case of radius authentication, vBNG will send the user's user name and password together with
other optional and configurable attributes to the radius server for authentication. The radius server will
reply with either “authentication accept” or “authentication deny” message. In the case of authentication
accept, radius can also send optional authorization attributes such as user IP, framed route, qos plans
etc. The following diagram shows this flow.

From the above diagram, we can see there are three possible interactions between the vBNG and the
radius
• vBNG sends authentication access requests with user credentials and other attributes.
• Radius sends vBNG access reject or access accept with certain attributes.
• Radius sends DMCOA messages to vBNG to change user online behaviors on the fly with certain
attributes.

Radius authentication configuration consists of the following two components:.

Radius Authentication Group Definition

First we have to define a radius authentication group where we specify parameters such as timeouts
and radius server IPs and access secrets. Here is an example:
radius authentication group radius_netElastic
server-type​ipv4-server
timeout ​3
retry-times​3
nas-ip-address [Link]
algorithm ​master
dead-time ​5
dead-count ​10
class-as-car disable
filter-id-type user-acl
server 1 ipv4-address [Link] port 1812 key netElastic​
radius-attribute translate-extend-vendor-specific
NetElastic-Qos-Profile-Name
src-vendor-id 2636
src-sub-id 250
exit
exit
The key elements in the radius authentication group definition are
●​ nas-ip-address: this is the vBNG router’s self address, which must be some address on the vBNG
router interface (physical or virtual) that the external radius server can reach.
●​ radius server IP, port, and secret: These are the external radius servers IP, port, and access
secret. You can configure up to 4 radius servers. The default port for radius authentication is
1812.
●​ radius-attribute translate-extend-vendor-specific: You can use this configuration to translate VSA
attributes from other vendors to netElastic VSAs. This feature is supported from version
release-1.12.55.B3P29. Currently the netElastic attributes that can be translated to are:
NetElastic-Domain-Name, NetElastic-Input-Average-Rate, NetElastic-Output-Average-Rate, and
NetElastic-Qos-Profile-Name. These translations can also be configured in the radius accounting
group definition.

Authentication Template Definition

A typical configuration of the authentication template with radius authentication is shown below.
bras
authentication radius_auth
authentication-type ​ radius
radius-authentication-group radius_netElastic
user-name-format ​ strip-domain
nas-port-format ​ class1
called-station-id-format​ class1
nas-port-id-format class1
calling-station-id-format class1
invalid-vlan-tag ​ 0
exit
exit
​
The authentication template configures:
1.​ How authentication should be done (Radius, Local, etc)
2.​ How the vBNG will form and send auxiliary Radius attributes with authentication request packet.

Some of the typical fields in the template are:

●​ authentication-type : this field dictates how the subscriber should be authenticated. Here are
the options:
○​ local : local authentication, user must be configured locally on the vBNG.
○​ local-radius : vBNG will try local authentication first. If a user cannot be found locally,
vBNG will send authentication requests to Radius for Radius authentication. User access
attempts will be rejected if both fail.
○​ none : no authentication. As noted earlier, you still need to create an authentication
template and set the authentication-type to this value even if you don’t need
authentication.
○​ radius : Radius only. If a user cannot be authenticated through radius, user access
attempts will be rejected.
○​ radius-local : vBNG will try Radius authentication first. If a user cannot be authenticated
through Radius, vBNG will try local authentication. User access attempts will be rejected
if both fail.
 ○​ radius-none : vBNG will try Radius authentication first. If Radius does not reply to the
authentication request, vBNG will authenticate the user as if the user’s
authentication-type is set to none.
●​ radius-authentication-group : specify the Radius authentication group you would have defined
under “radius authentication group” where you specify radius server access information (IP, ports,
and secret)
●​ authen-fail : This field specifies the user's online behavior when authentication fails. You can
choose to let users offline or online but put in a specified domain.
●​ user-name-format : This specifies how vBNG extracts the user name from the user name string
sent from the subscriber. This generally applies to PPPoE connections and assumes the user
name string from the subscriber is in the general form of “stringA@stringB”, where @ denotes
the delimiter character set under “bras -> domain-name-delimiter”. Here are the options:
○​ strip-domain : “stringA” will be used as username
○​ include-domain : “stringA@stringB” will be used as username
○​ only-domain : “stringB” will be used as username
●​ nas-port-id-format : This specifies how vBNG forms the NAS-PORT-ID (RADIUS Attribute
87)string to be sent to radius.
○​ class1 : The NAS-PORT-ID string will be formulated as
"slot=xx;subslot=xx;port=xx;vlanid=xx;vlanid2=xx". For single vlan (dot1Q), vlanid carries
and vlan ID and vlanid2 will be 0. For double vlan (QinQ), vlanid carries inner vlan ID
(cVlan) and vlanid2 will carry outer vlan ID (sVlan)
○​ class2 : The NAS-PORT-ID string will be formulated as
"slot=xx;subslot=xx;port=xx;vlanid=xx;vlanid2=xx". For single vlan (dot1Q), vlanid carries
and vlan ID and vlanid2 will be 0. For double vlan (QinQ), vlanid carries outer vlan ID
(sVlan) and vlanid2 will carry inner vlan ID (cVlan). Note that for QinQ, how vlan IDs are
carried for class2 is exactly the opposite of that for class1.
○​ class3 : The NAS-PORT-ID string will be formulated as “netElastic eth
0/slot/subslot/port:{vlan|[Link]}”.
○​ class4 : The NAS-PORT-ID string will be formulated as “{atm|eth|trunk}
NAS_slot/NAS_subslot/NAS_port:[Link]
AccessNodeIdentifier/ANI_rack/ANI_frame/ANI_slot/ANI_subslot/ANI_port[:ANI_XPI.ANI
_XCI]”, where
■​ atm|eth|trunk: BRAS/SR interface type。”atm’ for atm interface; “eth” for
Ethernet interface; and “trunk” for Trunk type Ethernet interface. Currently this
field is set to “eth” by vBNG.
■​ NAS_slot：BRAS slot ID.
■​ NAS_subslot：BRAS sub slot ID.
■​ NAS_Port：BRAS port number.
■​ XPI: If the interface type is ATM, XPI corresponds to VPI，XPI is an integer value
within range 0~255；If the interface type is eth or trunk, XPI corresponds to
PVLAN，XPI is an integer value within range 0~4095.
■​ XCI：If the interface type is ATM，XCI corresponds to VCI，XCI is an integer value
within range 0~65535；If the interface type is eth or trunk, XCI corresponds to
CVLAN，XCI will be an integer value within range 0~4095
■​ AccessNodeIdentifier/ANI_rack/ANI_frame/ANI_slot/ANI_subslot/ANI_port[:
ANI_XPI.ANI_XCI]: This is L2 access information. Currently vBNG sets these
values all to 0
○​ class5 : The NAS-PORT-ID string will be the Circuit-ID in PPPoE or IPoE packets.
 ○​ KEEP_AGENT_CIRCUIT_ID: The NAS-PORT-ID string will be formulated as “eth
slot/subslot/port:[Link]”.
○​ USER_DEFINED: The NAS-PORT-ID string will be formulated as a user defined string.
Currently only “slot”, “port”, and “vlan” are supported.
●​ nas-port-format: This specifies how vBNG forms the NAS-PORT (RADIUS Attribute 5) value (32
bit) to be sent to radius.
○​ class1: slot ID（8 bit）+ sub slot ID (4 bit) + port number（8 bit）+ VLAN(12 bit). For QinQ，
VLAN is the inner VLAN ID.
○​ class2: slot ID（12 bit）+ sub slot ID (8 bit) + VLAN(12 bit). For QinQ，VLAN is the inner
VLAN ID.
○​ class3: slot ID（3 bit）+ sub slot ID (1 bit) + port number (4 bit) + QinQVLAN(12 bit) +
VLAN(12 bit).
○​ class4: slot ID（8 bit）+ sub slot ID (4 bit) + port number（8 bit）+ VLAN (12 bit). For QinQ，
VLAN is the outer VLAN ID.
○​ class5: Only inner VLAN ID.
●​ calling-station-id-format: This specifies how vBNG forms the Calling-Station-ID (RADIUS
Attribute 31) to be sent to radius
○​ class1: user MAC address in the form of “xx:xx:xx:xx:xx:xx”
○​ class2: “certusnet#0/slot/subslot/port #{vlan|exVlan:inVlan}”
○​ class3: “xx-xx-xx-xx-xx-xx@vlan”，where “@” represents the delimiter defined in the
domain-name-delimiter under bras.
○​ class4: The value of “PPPoE remote-id”
●​ called-station-id-format: This specifies how vBNG forms the Called-Station-ID (RADIUS
Attribute 30) to be sent to radius
○​ class1: configured “webserver-ssid” on the vBNG
○​ class2: The value of “PPPoE service-name”

NOTE: We only explained a few of the Radius attributes that are sent over to Radius with
authentication request packets. The complete list can be found from the following link.

List of vBNG Radius Attributes Sent With Access Request.

Check Authentication Request Status

Passing authentication is the first step for a subscriber to get online. When an authentication request
fails, it is important to be able to check access details such as what were the user access credentials
received by vBNG, what were actually sent to Radius for authentication, what were the radius reply
messages for a particular access request, etc. vBNG provides multiple ways to display access
information at this level of detail.

Check Radius Access Status with radius-ping Test

For radius authentication, the first thing you want to try is to ensure radius can accept your
authentication request. This can be tested by using command radius-ping. Radius-ping can test
both radius authentication and radius accounting. It exercises the whole radius authentication or
accounting protocols with a test user as shown in the following example.
domain# radius-ping authentication group my-radius-auth-grp user-name
test_user password test_user_pw pap
 Ping radius authentication-group my-radius-auth-grp with test_user at
2020-01-08 07:58:31!
Ping server [Link] at 2020-01-08 07:58:31!
Reply from server [Link] access accept at 2020-01-08 07:58:31!
domain#
In the above example, you can see that we tested with user credential test_user/test_user_pw
and Radius replied with an access accept message. The radius-ping test, when successful, will also
return the radius reply attributes sent from the radius server. Being able to simulate an authentication
request and see exactly what attributes are sent back from radius is immensely helpful when
integrating the BNG router with radius servers.

NOTE: If the test user's username or password contains spaces or the character !, you must use
quotation marks ("") to explicitly define the boundaries of the username and password strings.
Below is an example of a ping test with a username that includes spaces and a password containing
the ! character. ​
radius-ping authentication group my-radius-auth-grp user-name “test user”
password “testUserPassword!!!” pap

By default, the radius-ping test does not carry any circuit level attributes such as
calling-station-id, nas-port, nas-port-id, etc. However, you can simulate sending this
type of information to a radius server with a radius-ping test by configuring the radius
ping-test group as shown in the following example.
radius ping-test group
authentication-include service-type 2345
authentication-include calling-station-id vlan-100
authentication-include nas-port-id 2345
exit

Check Radius Access Status By Examining Radius Log

All radius access activities will be logged to the radius log file which is located at
/var/log/certus/log. You can examine the log file to find out all radius related activities
including radius authentication request and reply messages.

Check Access Status by Examining On-line Fail Records

vBNG also keeps track of failed access records with the reason why the access attempts failed. This
provides very helpful information as to why access attempts failed and thus provide hints on how to
correct them. To display these records, type the command show vbras online-fail-record.
Here is a sample of the records. To clear this record, use the command
clear-vbras-online-fail-record.

Radius Authorization
If authentication is not successful, radius will reply with an access reject message that carries no
attributes. If authentication is successful, radius will reply with an accept message that can carry relevant
attributes to direct the vBNG how to handle certain properties of the user. This process is called radius
authorization and its behavior is defined in the user authorization template.

Authorization Template
The authorization template serves two purposes:
1.​ Control how subscriber’s authorization attributes such as IP address, qos plan, acl rule etc.
should be obtained
2.​ Specify locally defined authorization attributes such as IP address, qos plan, acl rule etc.
These locally defined parameters such as sub car, user qos , acl, etc will be applied to the
subscribers if the radius does not reply with corresponding attributes AND the authorization
type is set to mixed-radius or local. Keep in mind that the locally defined attributes will not be
used if the authorization type is set to radius.
3.​ If you need to send any authorization attributes such as IP address, qos plan, acl rule etc from
radius, you will need to set authorization-type to mix-radius or radius (see below).

A typical user authorization template is shown below.

bras
authorization radiusAuthorization
authorization-type mix-radius
user-qos-profile user_qos_1000kbpsUp_5000kbpsDown
user-acl-profile user_acl_list
sub-car-input cir 2000 pir 2000 cbs 250000 pbs 250000
sub-car-output cir 4000 pir 4000 cbs 500000 pbs 500000
bind nat-domain-name myNatRule
nat-type inside
radius-nat-switch disable
exit
exit
​
Some of the typical fields in the template are:
●​ authorization-type: this field dictates how the subscriber’s authorization attributes should be
obtained. Here are the options:
○​ local: user’s authorization attributes strictly come from locally configured values on the
vBNG.
○​ radius: user’s authorization attributes strictly come from radius.
○​ mix-radius: vBNG will use authorization attributes coming from the radius first. It will use
locally configured values only if these attributes are not sent from radius. ​
NOTE: we normally set this to mix-radius when using radius AAA. Setting the
authorization-type to local will let the router ignore any attributes from radius.
●​ user-qos-profile: this field specifies the user qos profile. ​
NOTE: the value specified here will only be honored when either authorization-type is local OR
authorization-type is mix-radius but radius does not send user-qos-profile.
●​ user-acl-profile: this field specifies the user acl rules. ​
NOTE: the value specified here will only be used when either authorization-type is local OR
authorization-type is mix-radius but radius does not send user-acl-profile.
●​ sub-car-input: this field specifies the user input (upload) rate limiting CAR parameters. ​
NOTE: Do not configure this parameter if the user qos profile is used for user rate control instead.
 ●​ sub-car-output: this field specifies the user output (download) rate limiting CAR parameters. ​
NOTE: Do not configure this parameter if the user qos profile is used for user rate control instead.
●​ bind nat-domain-name: this field specifies the NAT rule defined in the NAT section. ​
NOTE: the nat rule can not be sent from radius, it has to be statically configured here or do not
configure any nat rules here and make all nat rules global. See nat configuration application note
for details
●​ lease-time: this field specifies the lease time as if this lease time is sent from Radius. If the
authorization type is set to radius or mix-radius, the router will honor the lease time from radius
first. If none sent from radius and lease-time is defined here in the authorization template, this
lease time will be applied to the subscriber. If none sent from radius and lease-time is not defined
here in the authorization template, the lease time defined under the ip pool will be used.

Check Radius Reply Attributes with Radius-ping

Radius-ping is a built-in function in the netElastic’s vBNG router. Upon authentication success, it will
display the Radius reply attributes if any. It provides a convenient way to check what attributes the
Radius server sends back upon radius authentication request success. If you are using radius
authorization attributes, you should always do a radius-ping test to validate the radius server
response to see if they match your expectation. Here is an example of aradius ping test result.
netelastic# radius-ping authentication group radius_netElastic user-name
e4-b9-7a-88-f1-d5 password e4-b9-7a-88-f1-d5 chap
Ping radius authentication-group radius_netElastic with e4-b9-7a-88-f1-d5 at 2022-07-28
15:30:37!
code:access request(1)
identifier:244
length:110
authenticator:0285D50299D54EA
Ping server [Link] at 2022-07-28 15:30:37!
code:access accept(2)
identifier:244
length:72
authenticator:0784AF59F2E16E1
attribute:
​ type:Framed-IPv6-Route(99) length:27 value:2804:3ef0:e200::0/64 :: 1
​ type:Vendor-Specific(26) length:19 vendor-id:54268
​ type:QOS-Profile-Name(31) length:13 value:profile_20m
​ type:Framed-IP-Address(8) ​ length:6​ value:[Link]
Reply from server [Link] access accept at 2022-07-28 15:30:37!

​
In the above example, radius-ping test showed that the Radius server sent back these attributes:
●​ public attribute 99 - Framed-IPv6-Route with value 2804:3ef0:e200::0/64 :: 1
●​ private attribute 31- QOS-Profile-Name with value profile_20m
●​ public attribute 8 - Framed-IP-Address with value [Link]

Commonly used Radius reply attributes.

As explained earlier, with radius authentication success, radius could reply with attributes. These
attributes will overwrite locally configured authorization attribute values when authorization-type is set
to mix-radius in the authorization template. For a complete list of supported Radius reply attributes by
the vBNG, please refer to the table by the following link.
List of Radius Reply Attributes Supported by netElastic’s vBNG

Here we list out a few very commonly used attributes from the list with more detailed explanations.

Framed-IP-Address Attribute (public 8)

When a subscriber dials into the vBNG router configured for RADIUS authentication, the vBNG router
initiates the process of contacting the RADIUS server in preparation for user authentication. Typically,
the IP address of the dial-in host is not communicated to the RADIUS server until after successful
user authentication. However if the subscriber already has an IP assigned to it by the vBNG, the
vBNG can send the IP address of the dial-in host to the RADIUS server as attribute 8 together with
other user information, such as the user name, password to the RADIUS server.

After the RADIUS server receives the user information from the vBNG, it has two options:
●​ Regardless of whether the radius authentication request contains attribute 8 or not, if the user
profile on the RADIUS server already includes attribute 8, the RADIUS server will fill or override
the IP address sent by the vBNG with the IP address defined as attribute 8 in the user profile.
The address defined in the user profile is returned to the vBNG. The vBNG will then assign this
IP to the user.
●​ If the user profile on the radius server does not include attribute 8, the RADIUS server can
accept attribute 8 from the NAS, and the same address is returned to the vBNG.

The format to assign Framed IP address on FreeRadius is the following:

Framed-IP-Address=[Link]

Please note that for vBNG to accept the Framed-IP-Address attribute from Radius, a valid IP address
pool that contains the assigned IP needs to be defined and associated with the user’s access domain.
At authorization time for the user, vBNG will try to assign the user an IP from the defined pool unless
“Framed-IP-Address” is found in the Radius accept reply message. To instruct vBNG to exclusively
use the IP from Radius to assign to the user, you need to reserve the IP section that you intend to
assign from the Radius in the IP pool definition to prevent vBNG from assigning them by default.
Here is an example of IP pool definition with IP reservation (highlighted in red).
ippool group private_radius_pool
gateway-ip [Link] gateway-mask [Link]
lease-time ​ 3600
dns-primary [Link] secondary [Link]
ippool-status ​ unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
reserved-section reserved-start-ip [Link] reserved-end-ip
[Link]
exit
exit
Framed-Route Attribute (public 22)

A typical use case for Framed routes is for subscribers to advertise IPs that they own internally to the
outside world through the BNG router. Upon receiving the framed routes for a subscriber, the BNG
router will install the routes on the router’s routing table as user routes for the subscriber. If user
routes are advertised on the BNG router, these routes associated with the user will be advertised so
the subscriber’s private IPs will be known to the outside world.

With this attribute, Radius can specify the routes to be installed for the user on the vBNG’s routing
table. vBNG supports multiple framed routes per user. When forming the attribute string on the
Radius, multiple routes have to be separated by an agreed-upon route delimiter. The delimiter is
configured on the vBNG under “radius” as shown below. The default delimiter is “;” as shown in the
following example
domain# show running-config radius
radius vendor-id ​ 54268
radius accounting-on enable
radius attribute-usermac-as mac
radius framed-route-delimiter ";"
radius username-override disable
radius dmcoa group
server-type ipv4-server
exit
​
On the Radius, form the attribute string for the framed route with the delimiter defined on the vBNG.
Here is an example of Framed-Route attribute with three routes using the delimiter “;”
Framed-Route= [Link]/24 [Link] 100;[Link]/24 [Link] 110;[Link]/24 [Link] 1;

In the above example, we are assigning three routes associated with the user. They are
[Link]/24, [Link]/24, and [Link]/24. The Framed-Route string format is [route]
[next hop] [metric], where the next hop means the user itself when configured as [Link].

Please note that Framed-Route are simply routes that are installed/removed to the router when the
associated user goes online/offline. It does not necessarily have to be the routes that the user owns.
●​ If you use Framed-Route to specify the routes that the user actually owns, you will have to specify
the next hop to be [Link], which means the user itself. In this case, after the user is connected
and its Framed-Route is assigned, you will find that the next hop interface of the Framed-Route
will be the user’s vgi interface.
●​ If you use the Framed-Route to specify general routes that the user does not actually own, you
will then set the route’s next hop according to how you want the traffic to be routed to the routes
specified in the Framed-Route specification. For example, suppose you have internal hosting
services on the subnet of [Link]/24 and the next hop to that subnet is [Link]. If you
want a user to have access to the internal hosting service when the user is online, you can
achieve this by sending the framed route Framed-Route= [Link]/24 [Link] to
the user.
To check if the framed routes have been installed for a particular user on the vBNG or not, use the
show smgr-session detail user command. The assigned frame routes will be displayed under
the framed-route field in the list. If there are many subscribers on the router, you can filter the
smgr session detail list by user name, IP, MAC etc (e.g. show smgr-session detail
by-user-name e4-b9-7a-88-f1-d5).

Framed-IPv6-Route (public 99)

With this attribute, Radius can specify the IPv6 routes to be installed for the user on the vBNG’s
routing table. Here is an example of the Framed-IPv6-Route attribute which has three parts to itself:
prefix, next hop, and metric.
Framed-IPv6-Route=2804:3ef0:e200::0/64 :: 1
In the above example “::” is the nexthop and it means the user itself.

To check if the framed IPv6 routes have been installed for a particular user on the vBNG or not, use
the show smgr-session detail user command. The assigned frame IPv6 routes will be
displayed under the framed-ipv6-route field in the list. If there are many subscribers on the
router, you can filter the smgr session detail list by user name, IP, MAC etc (e.g. show
smgr-session detail by-user-name e4-b9-7a-88-f1-d5).

User ACL

User ACL profile can be sent from radius to control subscriber’s access by defined ACL on the router.
With this operation, you can apply a subscriber's white list or black list on the fly.

The user ACL profile can be sent from radius either by the attribute Filter-Id (public 11) or the
private attribute NetElastic-Data-Filter Attribute (private 82). If both attributes are sent,
the public attribute Filter-Id (public 11) will take precedence and the netElastic private attribute
NetElastic-Data-Filter will be ignored.

The format to assign Framed IP address on Radius is like the following:

Filter-Id=my-user-acl-profile
NetElastic-Data-Filter=my-user-acl-profile

Note 1: the user access list profile “my-user-acl-profile” needs to be pre configured on the vBNG
router. Please refer to the user acl profile definition section on how to define user ACL profile
Note 2: user acl profile sent from radius can be treated either as normal user acl or as special acl for
walled garden redirect. If the user acl profile is intended for normal user acl, set “filter-id-type
user-acl” in the subscriber’s radius authentication template. Otherwise, if the user acl profile is
intended for walled garden redirect, set “filter-id-type special-acl” in the subscriber’s
radius authentication template.

NetElastic-Qos-Profile-Name Attribute (private 31)

This is netElastic’s private attribute. If the user profile on the RADIUS server already includes this
attribute, Radius can send the qos profile name to the vBNG and the user_qos_profile with that name
 will be applied to the user. With this attribute, you can change subscriber’s qos plan on the fly. The
format to assign qos profile on Radius is like the following:
NetElastic-Qos-Profile-Name =user_qos_profile

Note: The qos profile “user_qos_profile” needs to be pre configured on the vBNG router

NetElastic-Domain-Name Attribute (private 138)

This is netElastic’s private attribute. If the user profile on the RADIUS server already includes this
attribute, Radius will send the domain name to the vBNG and the domain with that name will be
applied to the user. With this attribute, you can change the subscriber's access domain on the fly.
The format to assign domain on Radius is like the following:
NetElastic-Domain-Name =user_domain

Note: The domain “user_domain” needs to be pre configured on the vBNG

Radius DMCOA
netElastic’s vBNG supports dynamic change of user’s online behavior through Radius DMCOA. The
following table lists the DMCOA actionable attributes.

List of Radius Reply/DMCOA Attributes Supported by netElastic’s vBNG

Please note that the table lists attributes shared between radius reply and DMCOA messages. Only the
attributes listed under “DMCOA only” or “Both” are DMCOA actionable.

To enable DMCOA on the vBNG, all you need to configure is to create the DMCOA group and add radius
servers to the group as shown in the following example. After the dmcoa group is configured, the vBNG
is ready to accept DMCOA requests. You can configure up to 16 radius servers in the DMCOA group.
Radius DMCOA always uses port 3799 for communication with the vBNG router.
radius dmcoa group
server-type ipv4-server
server 1 ipv4-address [Link] key radiusKey
server 2 ipv4-address [Link] key radiusKey
server 3 ipv4-address [Link] key radiusKey
exit

Here are a few examples of DMCOA requests withFreeRadius.

Disconnect Subscribers
Subscribers can be disconnected via radius DMCOA messages either by accounting ID or by user
name as shown in the following example

# echo "User-Name=somebody" > coa_message.txt

# echo "NAS-IP-Address=[Link]" >> coa_message.txt
 # cat coa_message.txt | radclient -x [Link]:3799 disconnect radius_secret

Sending Disconnect-Request of id 214 to [Link] port 3799

​ Acct-Session-Id = "D91FE8E51802097"
​ User-Name = "somebody"
​ NAS-IP-Address = [Link]
rad_recv: Disconnect-ACK packet from host [Link] port 3799, id=214,
length=20

Switch Subscriber’s QoS Plan

If you want to switch a user's QoS plan on the fly without disrupting the user's online status, you can
do so by the user’s username or accounting ID with the netElastic’s private attribute
“NetElastic-Qos-Profile-Name” via a radius COA message as shown in the following example.
# echo “User-Name = 84-2b-2b-aa-86-4f > coa_message.txt
# echo “Session-Timeout = 56000” >> coa_message.txt
# echo “Idle-Timeout = 9990” >> coa_message.txt
# echo “Acct-Interim-Interval = 8” >> coa_message.txt
# echo “NetElastic-Qos-Profile-Name = user_20M_updown” >> coa_message.txt
# cat coa_message.txt | radclient -x [Link]:3799 coa radius_secret

Switch Subscriber’s Download and Upload Rates

If you want to switch a user's download and upload rates on the fly without disrupting the user's online
status, you can do so by the user’s username or accounting ID with the netElastic’s private attributes
“NetElastic-Output-Average-Rate” and “NetElastic-Input-Average-Rate” via a radius
COA message as shown in the following example where the subscriber’s download and upload rates
are set to 200Mbps and 50Mbps respectively assuming the rate unit is configured as bps in the user’s
access domain
# echo “User-Name = 84-2b-2b-aa-86-4f > coa_message.txt
# echo “NetElastic-Output-Average-Rate = 200000000” >> coa_message.txt
# echo “NetElastic-Output-Average-Rate = 50000000” >> coa_message.txt
# cat coa_message.txt | radclient -x [Link]:3799 coa radius_secret
​
NOTE: the units of the download and upload rates can be configured either as kbps or bps. The rate
unit can be configured under config -> bras -> domain [user domain] ->
radius-attribute subcar-unit [bps/kbps]

User Reauthentication
There are situations where you need to let the subscriber go through the authentication process again
without user initiation. For example, users can get online initially for signing up purposes and are put
on a special domain after radius rejection. The special domain will direct their traffic to a portal
server to signup for service. After they sign up for services, their records will be created in the radius
database. Now you would like them to go through the re authentication process again so they can
get online as a registered user. Since version 1.9.44.B17, you can do this without user initiation by
sending the user re-authentication COA message as shown in the following example.
 # echo “User-Name = 84-2b-2b-aa-86-4f > coa_message.txt
# echo “Re-Authentication = 1” >> coa_message.txt
# cat coa_message.txt | radclient -x [Link]:3799 coa radius_secret

Put Subscriber to Walled Garden

Sometimes it is needed to control a subscriber's access to certain websites and services to push
certain notifications and special services to the subscriber. The walled garden feature in the vBNG
allows the ISP to direct subscribers’ http traffic to certain websites and to restrict their access to the
internet. This feature can be dynamically turned on and off via Radius COA while the subscriber is
online. To configure the walled garden service and make the service executable via Radius COA,
please follow this guide

Radius Accounting
netElastic’s vBNG supports Radius accounting. After enabled and setup, the vBNG will periodically send
subscriber’s accounting records to the designated Radius accounting server. The following link is a table
that lists the radius accounting attributes sent from the vBNG to radius accounting servers.

List of vBNG Radius Accounting Attributes.

Enable Radius Accounting

To enable Radius accounting, follow the following steps:
1.​ Create a radius accounting group where multiple radius servers can be specified.
2.​ Create a radius accounting template that binds the radius accounting group created in step 2.
Since many of the radius accounting behaviors are defined in the radius accounting template,
more detailed information about radius accounting template definitions will be provided as a
separate section next.
3.​ Bind the radius accounting template created in step 3 in the user’s access domain. At this
point, all subscribers using this access domain will be subject to the radius accounting behavior
defined in step 3.
4.​ Turn on radius accounting (optional). This is a global switch under config -> radius ->
accounting-on. The accounting-on setting is a feature where, when enabled, the BNG sends
a special accounting message to the Radius server upon the BNG reboot/reset events to notify
the Radius server to reset/log-off all existing sessions.
Here is an example of the above mentioned configurations.
! step 1: create a radius accounting group
radius accounting group radius_acct_grp
server-type​ ipv4-server
timeout ​3
retry-times​ 3
nas-ip-address [Link]
algorithm ​ all ! use all if records need to be sent to multiple servers
dead-time ​ 5
dead-count ​ 10
flow-unit ​ byte
server 1 ipv4-address [Link] port 1813 key radiusKey
 ! configure additional accounting servers if duplicate accounting records need
! to be sent to multiple servers. You can configure up to 4 servers
server 2 ipv4-address [Link] port 1813 key radiusKey
exit

! step 2: create a radius accounting template

bras
accounting radiusAccounting
accounting-type ​ radius
accounting-update ​ 600
first-radius-accounting-group radius_acct_grp
accounting-start-fail ​ online​
accounting-start-mode delay-time 2
accounting-update-fail online
accounting-update-immediately disable
l2tp-accounting ​ vpdn-model
user-name-format ​ strip-domain
nas-port-format ​ class1
called-station-id-format ​ class1
service-type ​ 1
nas-port-id-format class1
calling-station-id-format class1
invalid-vlan-tag ​ 0
exit
exit

! step 3: bind accounting template in the domain

bras
domain myDomain_Radius
bind authentication-template radiusAuthentication
bind accounting-template radiusAccounting
bind authorization-template radiusAuthorization
vgi ​ vgi1
domain-status ​ unlock
user-routing-distribute ​ disable
user-ipv6-routing-distribute disable
tunnel-domain ​ disable
flow-statistic ​ enable
radius-attribute qos-acl-profile no-exist-policy offline
radius-attribute qos-profile no-exist-avp online
quota-out offline
bind-pool 1 localPool
exit
exit

! step 4 (optional): turn on radius accounting

radius accounting-on enable

More About Radius Accounting Templates

In the accounting template as shown in the above example, you can specify what accounting
attributes of the subscribers for the vBNG router to send to the radius as accounting records. Here is
the list of some of the most popular accounting attributes and their formats based on the format
specifications configured under the radius accounting template.
●​ User-Name​
Assuming the general user name format is “userName@domain”, where @ is the delimiter
configured under the key domain-name-delimiter under bras configuration, the content of the
 User-Name attribute in the radius accounting records depends on how the key
user-name-format is configured, which can take any of the following values:
○​ strip-domain: “username”
○​ include-domain: “userName@domain”
○​ only-domain: “domain”
●​ accounting-update
This sets the accounting update interval in seconds. When making changes to the accounting
update interval on the fly, you do need to reconnect the existing users in order to apply the
updated accounting interval to the existing subscribers. Subscribers connected after the
change should honor the updated interval immediately..
●​ accounting-start-mode
This sets when the accounting start message will be sent to radius.
○​ immediately: accounting start message will be sent immediately after the user is online.
○​ delay-time [x] : accounting start message will be sent x seconds after the user is online.
It is important to set a meaningful delay time (e..g 2 seconds) for dual stack access so
the accounting start message can have information from both stacks.
●​ accounting-update-immediately
This sets when the first accounting update message will be sent to radius.
○​ enable: first accounting update message will be sent immediately after the user is online.
○​ disable : first accounting start message will be sent at the first scheduled accounting
update interval after the user gets online
●​ service-type
This sets the value of the radius attribute service type (attribute 6). The BNG router will send
this to the radius server as part of the accounting record. Some radius billing systems rely on
this field to classify services. You can set this value to any value from 1 to 11. Please refer to
RFC2865 for details.
●​ Nas-Port-Id​
Nas-Port_Id can take the following values depending on how the key nas-port-id-format is
defined. nas-port-id-format can take any of the following values:
○​ class1: "slot=xx;subslot=xx;port=xx;vlanid=xx;vlanid2=xx”. For Dot1q, vanid is vlan and
vlanid2 will be 0. For QinQ, vanid is inner vlan and vlanid2 will be outer vlan.
○​ class2: "slot=xx;subslot=xx;port=xx;vlanid=xx;vlanid2=xx”. For Dot1q, vanid is vlan and
vlanid2 will be 0. For QinQ, vanid is outer vlan and vlanid2 will be inner vlan.
○​ class3: the attribute sting will be “netElastic eth 0/slot/subslot/port:{vlan|[Link]}”
○​ class4: the attribute sting will be “{atm|eth|trunk}
NAS_slot/NAS_subslot/NAS_port:[Link]
AccessNodeIdentifier/ANI_rack/ANI_frame/ANI_slot/ANI_subslot/ANI_port[:ANI_XPI.ANI
_XCI]”, where:
■​ {atm|eth|trunk}: interface type with this mapping atm->ATM, eth->Ethernet,
trunk->Ethernet trunk.
■​ NAS_slot, NAS_subslot, NAS_port: NAS slot, subslot, and port number.
■​ XPI: For ATM, XPI is the VPI value (0-255). For Ethernet, XPI is the PVLAN
value (0-4095).
■​ XCI: For ATM, XCI is the VCI value (0-65535). For Ethernet, XCI is that CVLAN
value (0-4095).
○​ class5: “Circuit-Id” for both IPoE and PPPoE
○​ keep-agent-circuit-id: “eth slot/subslot/port:[Link]”
 ○​ user-defined: Define your own string format. The available elements are [ slot, port,
vlan, second-vlan, third-vlan ]. Here is a sample user defined configuration “user-defined [
slot port vlan second-vlan ] format %d%d%d%d”
●​ Nas-Port​
Nas-Port is a 32-bit integer and its value changes depending on how the key nas-port-format is
defined. nas-port-format can take any of the following values:
○​ class1: [slotID(8bit)][subSlotID(4bit)][portID(8bit)][vlan (12bit)]. For QinQ, only the vlan
field will be the inner vlan ID. For example, Nas-Port 16785408 or 0x01002000 in hex
can be interpreted as slotID=1, subSlotID=0, portID=2, and vlan=0.
○​ class2: [slotID(12bit)][portID(8bit)][vlan(12bit)]. For QinQ, only the vlan field will be the
inner vlan ID.
○​ class3: [slotID(3bit)][subSlotID(1bit)][portID(4bit)][ [innerVlan(12bit)] [OuterVlan(12bit)].
○​ class4: [slotID(8bit)][subSlotID(4bit)][portID(8bit)][ [innerVlan(12bit)].
○​ class5: [0(20bit)][innerVlan(12bit)].
●​ Calling-Station-Id​
The content of the Calling-Station-Id attribute in the radius accounting records depends on how
the key calling-station-id-format is configured, which can take any of the following values:
○​ class1: user MAC address in the format of “xx:xx:xx:xx:xx:xx”
○​ class2: “certusnet#0/slot/subslot/port #{vlan|exVlan:inVlan}”
○​ class3: delimiter [delimiter char]: “xx-xx-xx-xx-xx-xx@vlan”, where “xx-xx-xx-xx-xx-xx” is
the user mac separated by char “-“, “@” is the configured delimiter char. “vlan” is the
user’s access vlan tag.
○​ class4: PPPoE or IPoE remote-id.
●​ Called-Station-Id​
The content of the Called-Station-Id attribute in the radius accounting records depends on how
the key called-station-id-format is configured, which can take any of the following values:
○​ class1: the webserver-redirect-ssid parameter configured under domain
○​ class2: PPPoE service-name

Check Radius Accounting Access with radius-ping Test

After setting up Radius accounting, the first thing you want to try is to ensure radius accounting can
go through to the radius server. This can be tested by using command radius-ping as shown in the
following example. The test exercises the whole radius accounting protocols with a test user as
shown in the following example.
netelastic# radius-ping accounting group radius_acct_grp user-name
84-2b-2b-aa-86-4f
Ping radius accounting-group radius_netElastic_accounting with 84-2b-2b-aa-86-4f
at 2021-02-19 18:09:54!
Ping server [Link] at 2021-02-19 18:09:54!
Reply from server [Link] accept at 2021-02-19 18:09:54!
netelastic#

Flow Based Accounting

netElastic vBNG router supports flow based accounting. You can define up to 8 flows and the router
will keep track of data usage of each flow for each user and send the flow usage data to radius via
the user’s accounting records. To configure flow based accounting, follow these steps:
 ●​ Use a class map to define the flows you would like to have separate usage accounting for. It
is a good practice to define the class map of the flow in a way that catches the traffic in both
the up and down directions so that we can tally both the up and down traffic usage under one
flow category.
●​ Define behaviors where you label flow accounting categories called DAA (destination address
accounting) number. You can define up to 8 categories. If you already have QoS rate control
behaviors defined for the intended flows, you can add flow accounting category labels in the
same behavior definition.
●​ Define policies that map flows’ class map definitions to the accounting category behavior
definitions. If you are using user QoS profiles for subscriber rate control, you need to
combine the rate control policy definitions with the flow based accounting policy definitions
together.
●​ Define user QoS profiles where you specify policies for both the input (upload) and output
(download) directions. It is a good practice to use the same policy for both up and down
traffic so the up and down traffic usage counts fall into the same flow accounting categories.
●​ Tie the defined user QoS profile to the user either statically by binding it to the user’s
authorization domain or dynamically by sending attributes from radius.

Example 1 - Separate Usage Accounting for Different Flows

Here is an example of a user QoS profile with rate control and flow based accounting for three flow
categories. They are Google cache with 30M symmetric rate limit and accounting category 8,
Facebook Cache with 30M symmetric rate limit and accounting category 7, and general internet with
8M symmetric rate limit and accounting category 1.

! define Facebook traffic ACL

access-list FB-ACL
rule 100 permit ip source any destination [Link]/26
rule 110 permit ip source [Link]/26 destination any
rule 200 deny ip source any destination any
exit
! define Google traffic ACL
access-list GGC-ACL
rule 100 permit ip source any destination [Link]/27
rule 110 permit ip source [Link]/27 destination any
rule 200 deny ip source any destination any
exit

! define FB traffic flow based on FB ACL

class_map FB-traffic match-way match-all
match ipv4-access-list FB-ACL
exit
! define GGC traffic flow based on GCC ACL
class_map GGC-traffic match-way match-all
match ipv4-access-list GGC-ACL
exit
! define all internet traffic
class_map all-traffic match-way match-all
match all
exit

! define Facebook rate and accounting level

behavior FB-Usage
 item 1
traffic-level 8
car cir 30000 pir 30000 cbs 3750000 pbs 3750000
exit
exit
! define Google rate and accounting level
behavior GGC-Usage
item 1
traffic-level 7
car cir 30000 pir 30000 cbs 3750000 pbs 3750000
exit
exit
! define general internet rate and accounting level
behavior Internet-Usage
item 1
traffic-level 1
car cir 8000 pir 8000 cbs 1000000 pbs 1000000
exit
exit

! define user qos policy that combine all the flows/behaviors together
policy Policy-8M
class_map FB-traffic behavior FB-Usage priority 8
class_map GGC-traffic behavior GGC-Usage priority 7
class_map all-traffic behavior Internet-Usage priority 1
exit

! define the user qos profile that can be tied to user sessions
bras
user-qos-profile Rate-Plan-8M
input-qos-policy Policy-8M
output-qos-policy Policy-8M
exit
exit

Example 2 - Total Usage Accounting Excluding IPTV

Here is another example user’s QoS profile definition where we define an accounting tally based on
all traffic except IPTV traffic flow which is defined as flows to and from fixed IPs. In this example, we
used two IPTV servers with addresses [Link]/32 and [Link]/32. The rate limit
for IPTV and internet is 5M and 3M respectively for the total 8M QoS plan.
! define ACL flows that capture only IPTV traffic
access-list traffic-iptv
rule 10 permit ip source any destination [Link]/32
rule 15 permit ip source [Link]/32 destination any
rule 20 permit ip source any destination [Link]/32
rule 25 permit ip source [Link]/32 destination any
rule 100 deny ip source any destination any
exit

! define ACL flows that capture all traffic except IPTV

access-list all-traffic-excluding-iptv
rule 10 deny ip source any destination [Link]/32
rule 15 deny ip source [Link]/32 destination any
rule 20 deny ip source any destination [Link]/32
 rule 25 deny ip source [Link]/32 destination any
rule 100 permit ip source any destination any
exit

! define a classmap for IPTV only traffic

class_map traffic-iptv match-way match-all
match ipv4-access-list traffic-iptv
exit

! define classmap for all traffic except IPTV

class_map all-traffic-excluding-iptv match-way match-all
match ipv4-access-list all-traffic-excluding-iptv
exit

! define a behavior that marks DAA accounting level 2 for ITPVT

! and also set the traffic rate limit for 5M
behavior usage-iptv
item 1
traffic-level 2
car cir 50000 pir 50000 cbs 6250000 pbs 6250000
exit
exit

! define a behavior that marks DAA accounting for all other traffic level 1
! and also set the traffic rate limit for 3M
behavior usage-excluding-iptv
item 1
traffic-level 1
car cir 30000 pir 30000 cbs 3750000 pbs 3750000
exit
exit

! define a policy that binds the above defined classmap and behavior ​
! together.
policy Policy-8M
class_map traffic-iptv behavior usage-iptv priority 8
class_map all-traffic-excluding-iptv behavior usage-excluding-iptv priority 1
exit

! define the user qos profile that can be tied to user sessions
bras
user-qos-profile Rate-Plan-8M
input-qos-policy Policy-8M
output-qos-policy Policy-8M
exit
exit

Check Flow Based Accounting Results

To check the flow based accounting is actually categorized by flows, you can check the radius log
(/var/log/certus/radius) and look for “accounting Consume Info-DAA” under accounting start
and interim records. You should see usage octet stats under traffic level 1, 2, etc that match
the traffic levels you defined in behaviors.

On the radius side, the usage octet counts will be sent by the following netElastic VSAs for each flow
level. The radius AV pairs value format is a string with content such as “level:2 value 234423”
NetElastic-Tariff-Input-Octets ​ 247​ string
 NetElastic-Tariff-Output-Octets ​ 248​ string
NetElastic-Tariff-Input-Gigawords ​ 249​ string
NetElastic-Tariff-Output-Gigawords ​ 250​ string

Translate Other Vendor’s VSAs

To better support inter-operation between netElastic’s vBNG and billing systems that are already
configured to work with existing BRAS routers from other vendors such as Cisco, Juniper, etc, from
version 1.12.55.B3P29 and onwards, the BNG router supports translation of commonly used private
attributes from other vendor's BRAS routers. With this support, your billing system does not need to be
changed at all and can send AVP pairs to our router as if we are the same as the existing BRAS routers.

The netElastic VSAs that can be translated to any other vendor’s attributes are:​

●​ NetElastic-Domain-Name -> specify authorization domain name

●​ NetElastic-Input-Average-Rate -> specify subscriber’s upload rate in bps
●​ NetElastic-Output-Average-Rate -> specify subscriber’s upload rate in bps
●​ NetElastic-Qos-Profile-Name -> specify subscriber’s QoS profile name

Any one or all four attributes can be configured and applied to both radius authentication and accounting
templates. Here is an example in which the 4 netElastic attributes listed above will be translated to
another vendor’s (vendor code 838) attribute 6, 4, 5, and 3

radius authentication group myRadiusAuthentication

server-type​ipv4-server
timeout ​3
retry-times​3
nas-ip-address [Link]
algorithm ​master
dead-time ​5
dead-count ​10
class-as-car disable
filter-id-type user-acl
server 1 ipv4-address [Link] port 1812 key netElastic
radius-attribute translate-extend-vendor-specific NetElastic-Qos-Profile-Name
src-vendor-id 838
src-sub-id​3
exit
radius-attribute translate-extend-vendor-specific NetElastic-Domain-Name
src-vendor-id 838
src-sub-id​6
exit
radius-attribute translate-extend-vendor-specific
NetElastic-Input-Average-Rate
src-vendor-id 838
src-sub-id​4
exit
radius-attribute translate-extend-vendor-specific
NetElastic-Output-Average-Rate
src-vendor-id 838
 src-sub-id​5
exit
exit
radius accounting group myRadiusAccounting
server-type ​ ipv4-server
timeout ​ 3
retry-times ​ 3
nas-ip-address​ [Link]
algorithm ​ master
dead-time ​ 5
dead-count ​ 10
flow-unit ​ byte
align-authenreply disable
server 1 ipv4-address [Link] port 1812 key netElastic
radius-attribute translate-extend-vendor-specific NetElastic-Qos-Profile-Name
src-vendor-id 838
src-sub-id​3
exit
radius-attribute translate-extend-vendor-specific NetElastic-Domain-Name
src-vendor-id 838
src-sub-id​6
exit
radius-attribute translate-extend-vendor-specific
NetElastic-Input-Average-Rate
src-vendor-id 838
src-sub-id​4
exit
radius-attribute translate-extend-vendor-specific
NetElastic-Output-Average-Rate
src-vendor-id 838
src-sub-id​5
exit
exit

Radius Troubleshooting
For radius authentication or other router and radius server interaction failures, here are some
recommended troubleshooting tips
1.​ Ping the radius server and make sure there is IP connectivity between the BNG router and the
radius server.
2.​ Do a radius ping as discussed above with a username and password combination that already
exists on the radius database. Check the response and returned attributes.
3.​ If subscribers can authenticate, but can not disconnect. Check DMCOA configuration to make
sure server IPs and radius secrets match what are configured under the radius server groups.

With radius authentication/accounting failures, the route will display certain error messages when queury
the failure message queues with the command “show vbras online-fail-record”. Here are some of the
radius related error codes and their meanings
 Error Messages
(from What does this mean Next Step
online-fail-record)
fd not match,
This means the router receives a RADIUS Change the DM/CoA request port
radius check
DM/CoA message, but the port number does not number to 3799 on the RADIUS client
dmcoa request
match the expected port number (3799). side.
failed
For authentication:
The error message does not mean the
Our RADIUS request packets use source ports user will be unable to get online
64001 to 64010, for a total of 10 ports. Each port permanently. It only indicates that the
supports 256 sending resources (packet attempt failed at that moment. Typically,
identifiers), resulting in a total of 256 × 10 = 2560 the user will retry (redial), and the
available sending slots. connection will succeed once congestion
subsides.
When a request is sent, a sending resource is
marked as used and is not released until either a For accounting:
RADIUS response is received or the request Increase the accounting update interval.
times out. If the RADIUS server responds slowly
while a large number of requests are generated There are cases where the RADIUS
radius client has
in a short period, it is possible to exhaust all server can be overwhelmed by a high
no available id
available sending resources. In this case, you volume of requests from the BNG,
resource
will see the error message: causing it to become slow or
"radius client has no available id resource". unresponsive. Starting from version
1.12.59.B4P18R2, you can control the
RADIUS accounting works in the same way, rate of RADIUS messages using the
except it uses source ports 64011 to 64020 (also command “radius max-send-speed
10 ports). [messageRate]” where messageRate
is the number of RADIUS request
Therefore, the most likely cause of this error is a messages sent to the server per second.
combination of a high volume of concurrent It can be configured with a value between
requests and slow RADIUS response times. 1 and 10,000,000. For a slow RADIUS
server, a typical setting is between 50
and 100 requests per second.

This means that RADIUS authentication is Check the following:

configured, but the RADIUS authentication group 1) The authentication domain has an
radius client can
cannot be found. The most likely cause is that authentication template specified.
not find group
the RADIUS authentication group is not specified 2) The authentication template has a
name
in the authentication template. bound RADIUS authentication group

receive packet
check the Radius configuration or restart
authenticator This means that the Radius is not using the
the Radius server
check failed correct key/passcode for the reply packets
Access Control with ACL
vBNG router offers various ways of flow access controls with ACLs. The defined ACLs can be applied
both to the applicable interfaces and individual subscribers for the vBNG use case . We will show a few
use cases with examples below.

User ACL to whitelist traffic from known IPs and apply to the interface.

! block all traffic except those from known soruces

access-list allow-list
rule 10 permit ip source [Link]/24 destination any
rule 20 permit ip source [Link]/32 destination any
rule 100 deny ip source any destination any
exit

! apply src spam block list to the wan interface

interface 10gei-1/1/0
bind acl in ipv4 allow-list
ipv4 address [Link] 29
exit

Use ACL to blacklist traffic to/from known bad IPs and apply to an interface
There are situations when you have a list of known bad IP addresses from which rogue services such as
spam emails or DDoS attacks originated. To block them from accessing your network, you can create
access control lists (ACL) and apply them to the appropriate network interfaces as shown in the following
example. ​

! block all traffic going to these known spam hosts

access-list spam-dst-block-list
rule 10 deny ip source any destination [Link]/24
rule 20 deny ip source any destination [Link]/32
rule 100 permit ip source any destination any
exit

! block all traffic coming from these known spam hosts

access-list spam-src-block-list
rule 10 deny ip source [Link]/32 destination any
rule 20 deny ip source [Link]/32 destination any
rule 30 deny ip source [Link]/28 destination any
rule 100 permit ip source any destination any
exit

! apply dst spam block list to lan interface

 interface 10gei-1/1/1.100
bind acl out ipv4 spam-dst-block-list
dot1q 100
exit

! apply src spam block list to the wan interface

interface 10gei-1/1/0
bind acl in ipv4 spam-src-block-list
ipv4 address [Link] 29
exit

NOTE: The above example shows how to use ACL to control access in both the outgoing and incoming
directions. In reality these rogue services are usually TCP based, blocking in one direction will be
sufficient to prevent the rogue services from being established. As a good practice you should just block
the incoming traffic to your WAN interface to avoid using unnecessary ACL lists. Excessive use of ACL
lists (i.e. extraordinarily long lists) will adversely affect throughput performance.

Use ACL to block traffic to/from certain IPs and apply to subscribers
There are situations when you need to limit the user’s access to certain IPs in your network. This can be
accomplished by creating user ACL profiles and applying the user ACL profiles to the subscribers. The
configuration process involves:
1.​ Create ACL rules by flow characteristics. You can independently create ACL both in the “in”
(meaning coming to the subscriber) and “out” (meaning leaving the subscribers) directions
2.​ Create user ACL profiles based on the ACL rules created in step1.
3.​ Apply the user ACL profile to the subscriber either by statically binding the user ACL profile to the
user in the subscriber’s authorization template, or by sending the ACL profile name from radius.

The following is a configuration example where we limit the user’s access to an internet network
[Link]/24 by statically binding the user ACL profile in the subscriber’s authorization template.​

! block all traffic going to these known spam hosts

access-list internal-block-list
rule 10 deny ip source any destination [Link]/24
rule 20 deny ip source [Link]/24 destination any
rule 100 permit ip source any destination any
exit

! create user acl profile

bras
user-acl-profile internal-block-list
input-acl-profile internal-block-list
output-acl-profile internal-block-list
exit
exit

! bind the user acl profile to the user’s authorization template

bras
authorization my_authorization
 authorization-type mix-radius
user-acl-profile internal-block-list
nat-type ​ none
radius-nat-switch disable
exit
exit

Domain-based ACL
You can configure ACL rules using domain names instead of IP addresses or prefixes. However, please
note the following prerequisites and limitations for domain-based ACLs:
●​ To use domain-based ACLs, you must configure local DNS first. Ensure that local DNS is
configured before committing the domain-based ACL. Following this configuration order is crucial
to avoid potential ACL matching issues.
●​ Currently, domain-based ACLs do not support the * wildcard for matching. Using the * wildcards
may result in unexpected ACL behavior. Do not use the * wildcard in domain-based ACLs.

For detailed instructions on how to configure local DNS to support domain-based ACLs, please refer to
this section.

QoS Rate Control and Queues

vBNG supports rate limiting and priority queues QoS for various traffic flows. QoS can be applied to
subscribers, or interfaces, or both. Because of the high memory cost in implementing queues in software,
vBNG currently only supports priority queues QoS on interfaces. In general vBNG supports the following
types of QoS services
●​ Subcar Rate Limiting QoS
●​ QoS Profile Rate Limiting QoS
●​ Priority Queues. ​

The first option “Subcar Rate Limiting QoS” provides a quick and easy way to program the subscriber’s
connection rates either statically by configuration in the subscriber’s authorization template or dynamically
by sending radius attributes. This method offers one simple rate control to all flows. It does not have the
flexibility of controlling different rates with different flows as the other two options could. We will cover
more about this simple rate control method at the end of this session.

The second and third options offer the ultimate flexibility in controlling QoS both at the subscriber and
interface levels. They involve setting up QoS profiles on the vBNG router. Setting up QoS profiles on the
vBNG involves the following steps.
1.​ Create class_map to define the flows for which QoS behaviors are intended to be applied on.
class_map can be defined either directly by listing flow characteristics or by referencing defined
acl lists.
2.​ Create intended behaviors for the class_map rules defined. The behaviors supported by vBNG
are car, cbq, remark, etc.
 3.​ Create policies to create class_map and behavior pairs and set the relative priority among them.
Each policy can have up to 8 class_map/behavior pairs.
4.​ QoS policies can be directly applied to interfaces.
5.​ If QoS policies need to be applied to subscribers, user qos profiles need to be created where both
the upstream and downstream policies can be specified. The defined user qos profile is then
referenced in the authorization template of the user’s access domain. All users accessing
through this domain are subject to the QoS policies defined in the user qos profile.

It is important to note the nomenclature in the QoS configuration. The temps “input” or “output” are used
instead the colloquial names “upload” or “download” to describe the QoS traffic direction. Althoug
“input/ouput” always mean traffic “entering/leaving” an interface, the meaning of “input” or “output” in
reference to “upload” or “download” changes depending on what interfaces the QoS policies are applied
to. To be clear, the relationship between input/output and upload/download is

●​ If QoS is applied to users as user QoS, the reference point is the access interfaces. In this case,
input means upload to the internet and output means download from the internet.
●​ If QoS is applied to the WAN interfaces, the reference point will be the network interfaces. In this
case, input means download from the internet and output means upload to the internet.

The following diagram depicts the relationship among these components.

QoS Profile Based Rate Limiting

A more flexible way to control subscribe connection rate is through creating user QoS profiles and then
associate these profiles to subscribers either statically by domain/authorization template or by Radius
reply message attributes. The QoS profile creation flow and related association to authorization and
domain templates is illustrated below.

Next we will show some examples on how to create rate limiting QoS profiles. But before we do that,
please note that the QoS profile can be dynamically associated to subscribers either by Radius reply
attribute or Radius COA attribute, while domain can only be dynamically associated to subscribers by
radius reply attribute.

Defining a QoS profile involves the following steps.

●​ Flow definition using class-map: Here you can define the traffic flows for which you want to apply
QoS. You will use class-map to define flows. There are many different ways to define class map
based on flow characteristics. You can also use acl inside class map to define flows based on
access lists. See the examples below.
●​ Behavior definition: Here you can use CAR to define rate limiting QoS or priority queuing. For rate
limiting CAR settings, please refer to the subcar section.
●​ Policy definition: Here you create a QoS policy by mapping the flow definitions to the behavior
definition. You can define up to 8 different flow <-> behavior mappings with different priority
settings under one policy
●​ QoS profile definition: Finally you define a QoS profile where you put two QoS policies together
for both the input and output directions. For subscriber QoS, input means upload and output
means download.

QoS profile with multiple rates for different flows.

In the following example, we need to create a user qos profile with 10M download and 1M upload with
different rate settings favoring speedtest traffic as defined in the following table.

Keep in mind that the speedtest traffic in the example can be anything you would like to prioritize such
as VOIP, CDN, Google, Facebook, etc. The same following principle applies
1.​ define an access list to specify the flow for the traffic you would like to prioritize. This can be
based on destination IP, source IP, and ports, and any combination of them.
2.​ define a class map rule for the traffic based on the acl rule defined.
3.​ define a desired behavior for the traffic. This can be as separate rate or unlimited rate (i.e. set
to an arbitrarily large rate)
4.​ add to your existing QoS policy definition with a priority setting higher than that for your normal
internet traffic rates
Here is the complete configuration:

! speedtest flow1 classification

access-list flow1_acl_v4
rule 10 permit tcp source any gt 0 destination [Link]/32 eq 8080
rule 20 permit tcp source [Link]/32 eq 8080 destination any
rule 30 deny ip source any destination any
exit
access-list-v6 flow1_acl_v6
rule 10 permit tcp source any gt 0 destination 2001:df6:e300:500::18/128 eq 8080
rule 20 permit tcp source 2001:df6:e300:500::18/128 eq 8080 destination any
rule 30 deny ipv6 source any destination any
exit
class_map flow1 match-way match-any
match ipv4-access-list flow1_acl_v4
match ipv6-access-list flow1_acl_v6
exit

! speedtest flow2 classification

access-list flow2_acl_v4
rule 10 permit tcp source any gt 0 destination [Link]/32 eq 80
rule 20 permit tcp source [Link]/32 eq 80 destination any
rule 30 deny ip source any destination any
exit
access-list-v6 flow2_acl_v6
rule 10 permit tcp source any gt 0 destination
2a03:2880:f12f:183:face:b00c:0:25de/128 eq 80
rule 20 permit tcp source 2a03:2880:f12f:183:face:b00c:0:25de/128 eq 80
destination any
rule 30 deny ipv6 source any destination any
exit
class_map flow2 match-way match-any
match ipv4-access-list flow2_acl_v4
match ipv6-access-list flow2_acl_v6
exit

! speedtest flow3 classification

access-list flow3_acl_v4
 rule 10 permit tcp source any gt 0 destination [Link]/32 eq 80
rule 20 permit tcp source [Link]/32 eq 80 destination any
rule 30 deny ip source any destination any
exit
access-list-v6 flow3_acl_v6
rule 10 permit tcp source any gt 0 destination 2620:109:c002::6cae:a0a/128 eq 80
rule 20 permit tcp source 2620:109:c002::6cae:a0a/128 eq 80 destination any
rule 30 deny ipv6 source any destination any
exit
class_map flow3 match-way match-any
match ipv4-access-list flow3_acl_v4
match ipv6-access-list flow3_acl_v6
exit

! normal traffic classification

class_map all_traffic match-way match-any
match all
exit

! speed test flows rate limit

behavior CAR_150Mbps
car cir 150000 pir 150000 cbs 18750000 pbs 18750000
exit

! speedtest flow2 rate limit

behavior CAR_30Mbps
car cir 30000 pir 30000 cbs 3750000 pbs 3750000
exit

! speedtest flow3 rate limit

behavior CAR_20Mbps
car cir 20000 pir 20000 cbs 2500000 pbs 2500000
exit

! normal traffic download rate

behavior CAR_10Mbps
car cir 10000 pir 10000 cbs 1250000 pbs 1250000
exit

! normal traffic upload rate

behavior CAR_1Mbps
car cir 1000 pir 1000 cbs 125000 pbs 125000
exit

! user qos policy for 10M with priority given to speedtest

policy user_policy_10Mbps
class_map flow1 behavior CAR_150Mbps priority 8
class_map flow2 behavior CAR_30Mbps priority 7
class_map flow3 behavior CAR_20Mbps priority 6
 class_map all_traffic behavior CAR_10Mbps priority 1
exit

! user qos policy for 1M with priority given to speedtest

policy user_policy_1Mbps
class_map flow1 behavior CAR_150Mbps priority 8
class_map flow2 behavior CAR_30Mbps priority 7
class_map flow3 behavior CAR_20Mbps priority 6
class_map all_traffic behavior CAR_1Mbps priority 1
exit

! user qos profile definition. This profile name can be called from Radius
bras
user-qos-profile user_qos_1MbpsUp_10MbpsDown
input-qos-policy user_policy_1Mbps
output-qos-policy user_policy_10Mbps
exit
exit

QoS with priority given to speed test.

Here is a sample configuration for qos (20m down, 5m up) with priority given to speed test traffic
whose destination IPs are specified in an acl list.

access-list speedtest_acl
rule 10 permit ip source any destination [Link]/32
rule 20 permit ip source any destination [Link]/32
rule 30 permit ip source [Link]/32 destination any
rule 40 permit ip source [Link]/32 destination any
rule 200 deny ip source any destination any
exit
class_map all_traffic match-way match-any
match all
exit
class_map speedtest_traffic match-way match-all
match ipv4-access-list speedtest_acl
exit
behavior CAR_unlimited
car cir 1000000 pir 1000000 cbs 125000000 pbs 125000000
exit
behavior CAR_20000kbps
car cir 20000 pir 20000 cbs 2500000 pbs 2500000
exit
behavior CAR_5000kbps
car cir 5000 pir 5000 cbs 625000 pbs 625000
exit
policy policy_20000kbps
class_map speedtest_traffic behavior CAR_unlimited priority 8
class_map all_traffic behavior CAR_20000kbps priority 1
exit
policy policy_5000kbps
 class_map speedtest_traffic behavior CAR_unlimited priority 8
class_map all_traffic behavior CAR_5000kbps priority 1
exit
bras
user-qos-profile user_qos_5000kbpsUp_20000kbpsDown
input-qos-policy policy_5000kbps
output-qos-policy policy_20000kbps
exit
exit

QoS - Priority Based Queues

vBNG has six priority queues that can be assigned each to a subscriber or an interface. The
designator of these 6 queues are ef, af1, af2, af3, af4, be. Of these 6 queues, ef has the highest
priority and be has the lowest priority. af1, af2, af3, af4 are weighted fair queues whose priority is
weighted proportionally to the bandwidth assigned. With each queue, you can configure a limiting
bandwidth in kbps. af1, af2, af3, af4 are weighted fair queues and they share the same
priority which sits between ef and be.

Here is an example of using queues for different flows

! flow1 classification
access-list flow1_acl_v4
rule 10 permit tcp source any gt 0 destination [Link]/32 eq 8080
rule 20 permit tcp source [Link]/32 eq 8080 destination any
rule 30 deny ip source any destination any
exit
access-list-v6 flow1_acl_v6
rule 10 permit tcp source any gt 0 destination 2001:df6:e300:500::18/128
eq 8080
rule 20 permit tcp source 2001:df6:e300:500::18/128 eq 8080 destination
any
rule 30 deny ipv6 source any destination any
exit
class_map flow1 match-way match-any
match ipv4-access-list flow1_acl_v4
match ipv6-access-list flow1_acl_v6
exit

! flow2 classification
access-list flow2_acl_v4
rule 10 permit tcp source any gt 0 destination [Link]/32 eq 80
rule 20 permit tcp source [Link]/32 eq 80 destination any
rule 30 deny ip source any destination any
exit
access-list-v6 flow2_acl_v6
rule 10 permit tcp source any gt 0 destination
2a03:2880:f12f:183:face:b00c:0:25de/128 eq 80
rule 20 permit tcp source 2a03:2880:f12f:183:face:b00c:0:25de/128 eq 80
destination any
 rule 30 deny ipv6 source any destination any
exit
class_map flow2 match-way match-any
match ipv4-access-list flow2_acl_v4
match ipv6-access-list flow2_acl_v6
exit

! flow3 classification
access-list flow3_acl_v4
rule 10 permit tcp source any gt 0 destination [Link]/32 eq 80
rule 20 permit tcp source [Link]/32 eq 80 destination any
rule 30 deny ip source any destination any
exit
class_map flow3 match-way match-any
match ipv4-access-list flow2_acl_v4
exit

! regular_flows classification
class_map all_traffic match-way match-any
match all
exit

behavior flow1_queue
cbq queue ef bandwidth 100000
exit
behavior flow2_queue
cbq queue af1 bandwidth 40000
exit
behavior flow3_queue
cbq queue af2 bandwidth 50000
exit
behavior regular_queue
cbq queue be
exit
policy interface_queue_policy
class_map flow1 behavior flow1_queue priority 8
class_map flow2 behavior flow2_queue priority 7
class_map flow3 behavior flow3_queue priority 6
class_map regular_flows behavior regular_queue priority 1
exit

! Next apply this to interfaces.

interface gei-1/1/2.200
description "access inf"
bind qos in interface_queue_policy
bind qos out interface_queue_policy
nat inside
dot1q 200
exit

interface gei-1/1/3
description "network inf"
bind qos in interface_queue_policy
 bind qos out interface_queue_policy
nat outside
ipv4 address [Link] 24
exit

In the above example, we use the same policy for both input and output direction. In fact, we only
need to bind the queue policy in the outbound direction because the queue is only honored in the rx
direction of each interface. A normal practice would be to apply the queue policy in the outbound
direction for both the access and network interface as shown in the above example.

Here is another example using vlan to separate business traffic vs residential and give business traffic
higher priority over non-business traffic.

! match business traffic based on vlan

class_map business-traffic match-way match-any
match vlan inner 850-850
exit

! match all traffic

class_map all_traffic match-way match-any
match all
exit

! highest priority with max 10Gbps limit

behavior business_queue
item 1
cbq queue ef bandwidth 10000000
exit
exit

! lowest priority queue

behavior all_others_queue
item 1
cbq queue be
exit
exit

! create queue policy

policy interface_queue_policy
class_map all_traffic behavior all_others_queue priority 1
class_map business-traffic behavior business_queue priority 8
exit

! apply queue policy to access interface

interface gei-1/1/2.200
description "access inf"
bind qos out interface_queue_policy
nat inside
dot1q 200
 exit

! apply queue to network interface

interface gei-1/1/3
description "network inf"
bind qos out interface_queue_policy
nat outside
ipv4 address [Link] 24
exit

Applying QoS profiles to subscribers.

​
Once user QoS profiles are defined, they can be applied to the subscribers in the following ways:
●​ Statically bind to the user’s QoS profile in the user’s authorization template. The configuration
path is: bras -> authorization [authorization template name] ->
user-qos-profile [user qos profile name]
●​ Dynamically assigned to the user from the radius by the netElastic private attribute 31
“NetElastic-Qos-Profile-Name”

Allow/deny users when users QoS profiles do not exist

Sometimes the radius attributes such as the user QoS profile is lost during transmission
from the radius server to the BNG router due to various reasons such as radius server
overloading. If the user is allowed to be online without a QoS profile, the user’s bandwidth
won’t be controlled as intended. You can control the user’s online access behavior based
on if the user’s QoS profile is present or not

Use the switch radius-attribute qos-profile no-exist-avp

[online/offline] under bras->domain to control user’s online behavior when radius
reply message does not carry user QoS profile. When the value is set to offline, users
whose radius reply message does not have a QoS profile attribute will be denied
connection. This is especially important in order to prevent unintentional unlimited
bandwidth provision for subscribers whose QoS profiles are missing from radius.

Subcar Rate Limiting QoS

With subcar, you can independently control subscriber connection rate in both the upstream and
downstream directions. Subcar can be statically configured as part of an authorization template or it can
be dynamically assigned to a subscriber with Radius reply or Radius COA.
●​ Statically Configure Subcar​
subcar can be configured as part of an authorization template as shown below. The authorization
 template will be referenced in the subscriber’s access domain. ​

bras
authorization myAuthorization
authorization-type local
sub-car-input cir 2000 pir 2000 cbs 250000 pbs 250000
sub-car-output cir 20000 pir 20000 cbs 2500000 pbs 2500000
bind nat-domain-name myNatRule
nat-type ​ inside
radius-nat-switch disable
exit
exit
​
In the above example, the upstream rate is set to 2Mbps and downstream rate is set to 20Mbps.
The parameters used are:
○​ cir – committed information rate in kbps
○​ pir – peak information rate in kbps
○​ cbs – committed block size in bytes. This represents the number of bytes in a one second
interval with cir rate. So this value is usually set to 125×cir (kbps)
○​ pbs – peak block size in bytes. This represents the number of bytes in a one second
interval with pir rate. So this value is usually set to 125×pir (kpbs)​

NOTE: In the above example, the “authorization-type” is set to “local”. This means the subcar
rate defined here will be honored by the vBNG. If the “authorization-type” is set to “radius” the
subcar rate defined here won’t be used at all. If the “authorization-type” to or “mix-radius”, the
subcar rate defined here will only be used if there are no subcar attributes coming from radius.

NOTE: From version 1.12.55.B3P1 and onwards, you use only cir to configure subcar rate
control. Other subcar parameters (pbs, cbs, and pbs) will be calculated by the default rate control
algorithm. Here is an example of statically configured subcar rate for 20Mbps upload and 40Mbps
download. Note the unit of the cir value is in kbps.
bras
authorization myAuthorization
authorization-type mix-radius
sub-car-input cir 20000
sub-car-output cir 40000
nat-type ​ none
radius-nat-switch disable
exit
exit

●​ Dynamically Configure Subcar​

Subcar can also be dynamically assigned from radius either as radius authentication reply
attributes or via radius COA. The following VSA attributes are relevant for subcar configuration.

​ Attribute Name ​ Note

 NetElastic-Input-Average-Rate ​ upstream cir (bps)
NetElastic-Input-Burst-Size ​ upstream cbs (125×cir(kbps))
NetElastic-Input-Peak-Rate ​ upstream pir (bps)
NetElastic-Input-Peak-Burst-Size ​ upstream pbs (125×pir(kbps))
NetElastic-Output-Average-Rate ​ downstream cir (bps)
NetElastic-Output-Burst-Size ​ downstream cbs (125×cir(kbps))
NetElastic-Output-Peak-Rate ​ downstream pir (bps)
NetElastic-Output-Peak-Burst-Size​ downstream pbs (125×pir(kbps))

NOTE: Please note that unlike the rate units used in statically configured subcar parameters, the
rate units in subcar parameters sent from radius are in bps instead of kbps.

For example, if you need to set 50 Mbps download and 20 Mbps upload for a user, Radius should
reply with the following Radius attribute values to the user’s access request or via radius COA.

​ Attribute Name ​ Operator​ Value

NetElastic-Input-Average-Rate ​ := ​ 20000000
NetElastic-Input-Burst-Size ​ := ​ 2500000
NetElastic-Input-Peak-Rate ​ := ​ 20000000
NetElastic-Input-Peak-Burst-Size := ​ 2500000
NetElastic-Output-Average-Rate ​ := ​ 50000000
NetElastic-Output-Burst-Size ​ := ​ 6250000
NetElastic-Output-Peak-Rate ​ := ​ 50000000
NetElastic-Output-Peak-Burst-Size := ​ 6250000

NOTE: From version 1.12.55.B3P1 and onwards, you use only cir to configure subcar rate
control. Other subcar parameters (pbs, cbs, and pbs) will be calculated by the default rate control
algorithm. Use these two VSA attributes to set the user’s upload and download rates.​
​ NetElastic-Input-Average-Rate​
​ NetElastic-Output-Average-Rate ​
Keep in mind that units for these two radius attributes are in bps by default. For example, if you
need to set 20Mbps upload and 40Mbps download you need to set
NetElastic-Input-Average-Rate := 20000000
NetElastic-Output-Average-Rate := 40000000
Since these attributes are 32-bit integers, the maximum Subcar rate you can program is 4Gbps
when the rate unit is bps. From version 1.12.62.B4P26, the units for these two radius attributes
can be configured to be either in bps or kbps so you can potentially program the Subcars to
values larger than 4Gbps. To configure, type config -> bras -> domain [user domain]
-> radius-attribute subcar-unit [bps/kbps]

Subcar v.s QoS Profile Rate Limiting QoS

The vBNG supports rate limiting QoS either through subcar or through definition of rate limiting QoS
profiles. Each of these two methods has its own advantage and suitable use cases and they are meant to
complement each other.
●​ Subcar
 ○​ Easier to configure: minimal configuration is needed when used statically, or no
configuration at all on the vBNG when used dynamically through Radius reply attributes
or COA.
○​ Limited flexibility: With subcar the rate limit applies to all traffic flows. Subcar cannot
perform flow-based rate limiting.
●​ QoS Profile
○​ More complicated to configure: needs to configure class map, behavior, policy, and then
QoS profile.
○​ Maximum flexibility: Using QoS profile, you can achieve maximum rate limiting flexibility
based on many L2 and L3 flow characteristics.

Time Based QoS

vBNG supports time frame based QoS switching. Once configured, QoS rules will switch automatically to
desired rate or priority settings at the designated time frame. Time frame definitions repeat daily within a
24 hour period and are based on vBNG local time. Therefore, it is important to set the vBNG system
clock to local time.

To configure, you define the time frames first and then use it as one of the matching criteria in ACL rules.
The following is an example with the following time based rate control requirements:
●​ From 16:00-22:00 is prime peak with the bandwidth limited to 1M
●​ From 22:00-01:00 is secondary peak with bandwidth limited to 2M
●​ No limit on other time frames

Here is the configuration:

! define time range

time-range TR-16-22
daily start 16:00:00 end 22:00:00
exit
time-range TR-22-01
daily start 22:00:00 end 01:00:00
exit

! define classmap
class_map all_traffic match-way match-any
match all
exit

!define CAR rate limiter for different time frames

behavior peak-limiter
item 1
car cir 1000 pir 1000 cbs 125000 pbs 125000
tr-name TR-16-22
exit
item 2
car cir 2000 pir 2000 cbs 250000 pbs 250000
tr-name TR-22-01
 exit
exit

!define QoS policy

policy peak-policy
class_map all_traffic behavior peak-limiter
exit

!define user qos profile

bras
user-qos-profile peak-profile
input-qos-policy peak-policy
output-qos-policy peak-policy
exit
exit

NOTE 1: Not all behavior CAR or CBQ definitions need to be accompanied by a tr-name configuration. If
you do not want a CAR or CBQ to be tied to any time frame limitation, simply don’t configure tr-name
under that item.
NOTE 2: item [id] determines match priority. If you have multiple CARs and CBQs under behavior
definition with some of them tied to time frames and some of them not, always put the ones with tr-name
specifications at the top. The smaller the item value, the higher is that item’s priority.
NOTE 3: If all CARs or CBQs under behavior definition have tr-name specified and yet the union of
tr-name does not cover the whole 24-hour period. The uncovered segment of the 24-hour period will not
be subject to any CAR or CBQ rules.

DNS Relay Agent Configuration

DNS Relay Server Configuration

You can configure the vBNG router as the subscriber’s DNS server, in which case the vBNG will act as a
DNS relay server and cache the DNS entries from external DNS servers. The router will listen on both v4
and v6 DNS queries as long as
1.​ The DNS queries destination IPs (v4/v6) are IPs on the BNG router.
2.​ DNS relay is configured on the router

The configuration involves two steps:

1.​ Configure DNS server IPs and DNS relay IP as highlighted in the following example.
dns
relay-ip [Link]
name-server 1 [Link]
name-server 2 [Link]
name-server 3 2001:4860:4860::8888
exit
 a.​ The DNS relay-ip can be any IP that is local to the vBNG router, such as IPs on
lookback, vgi, physical, vlan, or trunk interfaces. The relay-ip can be either a v4 or v6
address. The router will use this IP as the source IP when formulating DNS query
packets to send to external DNS servers. If the relay-ip is IPv4 address, the DNS
query packets will be IPv4. Likewise, If the relay-ip is IPv4 address, the DNS query
packets will be IPv6. In either IPv4 or IPv6 DNS query packets formulated by the BNG
router, the query can be specified to lookup for IPv4, IPv6, or both addresses depending
on the query flag carried in the original DNS queries from the clients.
b.​ The name-server are the IP addresses of external DNS servers. It can be either IPv4
or IPv6 address. You can specify up to 5 external DNS servers. As in the above
example, there are three DNS servers configured. The router will always try to look up
from the first server. If the lookup fails from the first server, it will move on to the next
server, and so forth. ​

With a locally configured DNS relay agent on the vRouter, you do have the opportunity to
overwrite dns entries from the dns server with locally configured static entries under the key
static-item as shown in the following example.
dns
relay-ip [Link]
name-server 1 [Link]
name-server 2 [Link]
name-server 3 [Link]
static-item [Link]
ip-address 1 [Link]
ip-address 2 [Link]
exit
exit

2.​ Specify to use any IPs on the router as the subscriber’s DNS server IP in the subscriber’s IP pool
configuration as shown in the following example.
ippool group pool-906-Cambium
gateway-ip [Link] gateway-mask [Link]
lease-time 3600
dns-primary [Link]
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit
DNS Relay Server Validation.
After the DNS relay server is configured, you can validate its functionality by trying to ping a domain from
the router. For example, you can try “ping [Link]”. This should go through if the DNS
relay server is functioning properly and you do have connection to the internet from the router.

You can use the command “show dns-cache global” to display the DNS entries cached by the DNS
relay server.

DNS Relay Configuration for Domain-based ACL

To use domain based ACL, local DNS relay has to be configured so ACL DNS lookup happens on the
vBNG router. To configure DNS relay, follow these two steps

1.​ Configure DNS server IPs and DNS relay IP as highlighted in the following example. The DNS
relay IP can be any IP that is local to the vBNG router, such as IPs on lookback or other local
interfaces.
dns
relay-ip [Link]
name-server 1 [Link]
name-server 2 [Link]
name-server 3 [Link]
exit

2.​ Specify to use DNS relay IP as the subscriber’s DNS in the subscriber’s IP pool configuration as
shown in the following example.
ippool group pool-906-Cambium
gateway-ip [Link] gateway-mask [Link]
lease-time 3600
dns-primary [Link]
ippool-status unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit​

After creating DND relay configuration, you can create domain based ACL as shown in the following
example.​
access-list whitelist​
rule 10 permit ip source any destination-domain-name [Link]​
rule 20 permit ip source-domain-name [Link] destination any​
rule 30 permit ip source any destination-domain-name [Link]​
rule 40 permit ip source-domain-name [Link] destination any​
rule 4000 deny ip source any destination any​
exit
 Note: Please note that domain name-based Access Control Lists (ACLs) do not support wildcard
matches. For instance, entries like “*.[Link]” is not valid. Each domain name must be explicitly
specified in its entirety. For example, [Link] and [Link] are considered distinct domain
names. To match both, you would need to create two separate rules: one for [Link] and
another for [Link]. This approach ensures precise control over access permissions and avoids
unintended matches..

IPv4/IPv6 Dual Stack, IPv6 PD (Prefix Delegation)

Different Modes of IPv6 Address Allocations Supported

When a client device communicates with the BNG router using IPv6, it typically requires both a global
IPv6 address and a PD prefix, which the client uses to assign IPv6 addresses to devices behind it. The
global address can be one of the following:
●​ A stateful DHCPv6 IANA address, which must be assigned by the BNG router
●​ A stateless SLAAC address, which the client generates based on the prefix assigned by the
BNG router
●​ A link-local address, which does not require explicit assignment from the BNG router

The BNG router supports the following modes of IPv6 address assignment for connected devices:
●​ Global Address only. ​
This includes either a DHCPv6 IANA address or a stateless SLAAC address. In this mode, the
BNG router assigns only a global IPv6 address to the client.
●​ Global Address + PD​
The BNG router will assign a global address and PD. This includes the following combinations:
○​ IANA + IAPD
○​ SLAAC + IAPD
●​ PD only​
In this mode, the router assigns only a PD prefix to the client, with no explicit global address
assigned to the client device. The client communicates with the BNG router using its link-local
address.

With all the IPv6 address assignment modes supported by the BNG router, the router follows these rules
when determining which IPv6 address type to assign.

Global Address + PD Address Assignment

If all modes are enabled on the BNG router (meaning all corresponding address pools are configured),
the router will always attempt to assign IPv6 addresses based on the client’s request pattern.
When the client device makes either a stateful or stateless global address request along with a PD
request, the BNG router will attempt to generate the corresponding global address and PD prefix. If the
client requests a global address with PD but no matching address pool exists, the router will fail the
assignment and display the error: “no available pool.”

PD-Only Address Assignment

When the client makes neither a stateful nor a stateless address request but does request PD, the BNG
router will assign a link-local + PD combination.

There is no configuration option that forces the router to generate a link-local + PD combination. If this is
the behavior you require, you must ensure the client device requests PD only without requesting any
global address. For example:
●​ To prevent the client from requesting a stateless SLAAC address, disable the M flag under
the corresponding interface’s NDP configuration:
○​ ra auto-config managed-address disable
●​ To prevent the client from requesting either a stateless SLAAC address or a stateful IANA
address, disable both the M flag and the O flag:
○​ ra auto-config managed-address disable
○​ ra auto-config other disable​

Under any configuration, if the client requests a global address along with PD, the router will attempt to
assign a Global Address + PD [Link] no corresponding address pool exists, the router will fail the
assignment and display the error: “no available pool”. If your goal is to configure PD-only address
assignment and you wish to avoid this error, disable both the M and O flags as shown above in the NDP
configuration.

IPv4/IPv6 Dual Stack Authentication Process

The IPv4 and IPv6 online processes on the vBNG router are triggered independently by the DHCPv4 and
DHCPv6 processes on the client device. Regarding the online authentication process, the IPv4 and IPv6
stacks can be configured to authenticate independently, or the IPv6 stack can be configured to depend on
IPv4 being online first. In either case, if one stack is already online, the stack that attempts online later will
skip the authentication process, and its user session related information, if the online process is
successful, will be appended to the session of the stack that is already online. For example, if a
subscriber already has an IPv4 session on the router, subsequent IPv6 stack requests will bypass
authentication and proceed directly to the address allocation process. If IPv6 address allocation is
successful, the IPv6 addresses and related routes will be added to the existing user session.

The username and password for IPv4 and IPv6 stacks can be configured independently under config
-> bras -> ipoe template [template name].

To configure the online dependency between IPv6 and IPv4, follow the steps below.

●​ To set IPv6 stack depend on IPv4 being online first, configure the following:​
config -> bras -> ipoe template [template name] -> dhcp-v6 auth-on-up
mode on-IPv4
●​ To set IPv4 and IPv6 stack online independently,, configure the following:​
config -> bras -> ipoe template [template name] -> dhcp-v6 auth-on-up
mode independent

IPv6 Stack Configurations

IPv6 dual stack can be enabled for all the access types that the vBNG router supports. These access
types include IPoE, PPPoE, PPPoE over L2TP, PPPoE/IPoE over VPWS, ip host, leased line, etc. The
following example shows the configurations involved to enable IPv6 dual stack for IPoE. Enabling IPv6
dual stack for other access methods follows similar principles.

1.​ Enable IPv6 on related access, network, and vgi interfaces and set IPv6 addresses where
applicable
interface 10gei-1/1/0.15
nat outside
ipv4 address [Link] 27
ipv6 enable
ipv6 address 2804:3ef0:c0ca:c0ca::15 64
dot1q 15
exit​
interface 10gei-1/1/0.750
ipv6 enable
exit
interface vgi1
nat inside
ipv4 address [Link] 16
ipv6 enable
! Add applicable gateways for all the subnets that subscribers belong
! This includes iana, iapd, and slaac prefixes. For example, if
! subscribers are assigned iana and iapd, both subnets gateway needs
! to be configured.
ipv6 address 2804:3ef0:e100::1 112 ! gateway for address pool
ipv6 address 2a00:54e0:900::1 64 ! gateway for pd prefix pool
exit
In the above example, we:
●​ enabled IPv6 on the access interface 10gei-1/1/0.750
●​ enabled IPv6 on the network interface 10gei-1/1/0.15 and also set the IPv6 address on the
interface as 2804:3ef0:c0ca:c0ca::15/64
●​ enabled IPv6 on the subscriber’s access gateway interface vgi1 and also set the IPv6
gateway addresses on that interface. 2804:3ef0:e100::1 112/112 is gateway address for the
address pool and gateway address 2a00:54e0:900::1/64 is for the pd prefix​

2.​ Enable NDP on all access interfaces

ndp
interface 10gei-1/1/0.750
nud reachable-time 30000
dad attempts 1 interval 1000
ra suppress disable
ra interval 600
ra router-lifetime 1800
ra hop-limit 64
ra preference medium
ra auto-config managed-address enable
ra auto-config other enable​
ra prefix-lifetime valid-lifetime 2592000 preferred-lifetime 604800
exit
A few notes on ndp configuration:
●​ ra suppress enable/disable: Some CPE does not send RS and relies on periodic RA
from the router to maintain the IPv6 session. Setting “ra suppress diable” will enable
the router to periodically send RA to CPEs. Keeping this setting usually produces better
compatibility to different CPE devices. Please note that the router only periodically sends
RA to clients with stateful IPv6 address allocations. For clients with SLAAC addresses, the
router only sends RA messages in response to RS requests.
●​ ra interval [interval in seconds]: This sets the interval at which the router
periodically sends the RA message to the CPE devices. This value can be set anywhere
between 4 to 1800 seconds with 600 being the default. Keep in mind that the actual interval
at which the router sends RA messages to CPE devices is not fixed, but randomized
between the set interval and a lowered bound to reduce the probability of synchronization
with the advertisement from other routers on the same link [RFC4861 6.2.4]. The lower
bound of the RA interval is set on the router by the following rule:
○​ lowerBound=interval/3, if interval >= 9
○​ lowerBound=interval*3/4, if interval < 9
●​ ra router-lifetime [lifetime]: The sets the value of RA lifetime that the router
sends to the CPE devices. If CPE does not receive an RA before the RA lifetime expires,
the CPE shall disconnect from the router.
●​ ra auto-config managed-address enable/disable: Set this value to “disable”
for SLAAC mode IPv6 and “enable” for stateful DHCP IPv6 depending on how the CPE
should obtain its WAN IPv6 address. Essentially, setting this value to “enable” configures the
vBNG router to expect the CPE device to obtain both IANA and IAPD. Keep in mind that
enabling or disabling this setting only controls the flag bits set by the vBNG router in the
NDP (Neighbor Discovery Protocol) messages sent to the CPE. These flags suggest — but
do not enforce — whether the CPE should use stateful mode ("enable") or SLAAC mode
("disable") to acquire an IPv6 address for its WAN interface. However, the actual behavior
depends on the CPE's implementation. Some CPEs will attempt to request both IANA and
IAPD right away, while others might try SLAAC first and only switch to stateful DHCP if
SLAAC fails. To ensure maximum compatibility with various CPEs from different vendors,
we recommend the following:
○​ Set this value to enable if you want to enforce IANA+IAPD for IPv6 address
assignment
○​ Set this value to “disable” if you want the BNG router to accept the first successful
CPE WAN address assignment, and then add IAPD to its IPv6 stack if it’s configured.
For example, if the CPE first tries SLAAC and it succeeds, the BNG router will use
the SLAAC-assigned address as the router address. Any subsequent IAPD requests
will be accepted, but IANA requests will be denied.
●​ ra auto-config other enable/disable: This setting allows the vBNG router to
set/unset the appropriate flags in the NDP messages to notify the CPE device if there are
any other reasons that the CPE should run DHCPv6 with the vBNG router. For example, if
you need to run PD service with the CPE, you need to set the flag to enable so the vBNG
router can notify the CPE to run DHCPv6 to get the PD prefix from the vBNG router. Since
PD service is invariably going to be enabled for pretty much all practical dual stack use
cases, it is recommended to always set this setting to enable.
●​ ra prefix-lifetime valid-lifetime [prefix valid life time]
preferred-lifetime [prefix preferred life time]: This settings sets the
prefix valid life time and prefix preferred life time.
 ○​ prefix valid life time: This sets the prefix valid lifetime in seconds. If the
router does not receive any RS messages from the subscriber within this time
interval, the subscriber’s SLAAC stack will be cleared, and the assigned prefix will be
reclaimed. You should set this value to a large number if you intend for the CPE to
retain its assigned prefix for the duration of the user session.
○​ prefix preferred life time: This sets the prefix preferred lifetime in
seconds. The BNG router sends this value to the subscriber’s CPE device, instructing
it to periodically send Router Solicitation (RS) messages to the BNG router. This
informs the BNG that the assigned prefix is still in use and that the device intends to
continue using it. You want to set prefix preferred life time to be smaller
(e.g. 1/4) than prefix valid life time so the CPE can renew its prefix sooner
than the prefix expiration interval set under prefix valid life time
3.​ Enable dhcpv6 on all access interface
dhcpv6
dhcp enable
pool dhcpv6 ! define dhcp v6 property (lease time, dns)
! define dhcpv6 lease time (valid-lifetime) and
! dhcpv6 renew time (preferred-lifetime)
! preferred-lifetime is usually to set to be half of the
! valid-lifetime so the renew happens in the middle of the lease
life-time valid-lifetime 3600 preferred-lifetime 1800
! define ipv6 dns servers
dns-server 1 2001:4860:4860::8888
dns-server 2 2001:4860:4860::8844
exit
interface 10gei-1/1/0.750
mode server
dhcp-pool dhcpv6 ! apply defined dhcp v6 property to the interface
! when alloc-pd-always is set to enable, the router will always
! allocate iapd with iana request if iapd pool is configured
alloc-pd-always disable
! when alloc-na-always is set to enable, the router will always
! allocate iana with iapd request if iana pool is configured
alloc-na-always enable
exit
exit​

​
DHCPv6 can also be configured to work with external DHCPv6 servers when used as part of the
BNG function. In this case, it works with an external DHCPv6 server to manage IANA and/or IAPD
address assignments. The corresponding address or prefix delegation (PD) pools must be
configured and bound to the subscriber’s access domain.

DHCPv6 does NOT work with an external DHCP server when DHCPv6 is configured in standalone
mode.

To configure DHCPv6 to work with an external DHCP servers, you need to:
●​ Configure an address pool or PD (Prefix Delegation) pool that mirrors the address space
used by the external DHCPv6 server
 ●​ Reserve the address or prefix space that the external server will assign
●​ Bind the pool in the DHCPv6 configuration
Below is an example of a DHCPv6 configuration when operating as a relay agent:​

ippoolv6 addr-pool myAddressPool

dns-primary 13::13 secondary 14::14
pool-status unlock
warning-threshold 80
warning-exhaust disable
addr-range start-ipv6-ip 100:1:2::101 end-ipv6-ip 100:1:2::1220
reserved-addr-range reserved-start-ip 100:1:2::101 reserved-end-ip
100:1:2::200
exit
exit
ippoolv6 delegation-pool myPrefixPool
prefix-address 8:: prefix-length 48 delegation-length 64
reserved-prefix start-pd-address 8:0:0:1:: end-pd-address 8:0:0:2::
dns-primary 3::1 secondary 4::1
pool-status unlock
warning-threshold 80
warning-exhaust disable
exit

dhcpv6
dhcp enable
! relay remote-id is used to set the value of Option 37 (Relay Agent
! Remote-ID Option). Refer to RFC 4649 for details.
! 0 is the enterprise number, and myRemoveID is the remote ID.
! This feature is used to prevent relay loops.
relay remote-id 0 myRemoveID
pool myDHCPv6Pool
life-time valid-lifetime 600 preferred-lifetime 300
! The server-unicast-address is used when the client requests
! Option 12 (Server Unicast Option) (see RFC 8415 section 21.12),
! and if server-unicast is enabled on our DHCPv6 interface. In this
! case, we include the address in Option 12 in the reply sent to
! the client. This is unrelated to the relay server side.
server-unicast-address 100:1:2::250
rapid-commit enable
dns-server 1 8::8
dns-server 2 10::10
! This sets DHCPv6 option 24, also known as the Domain Search
! List option, specifies a list of domain names that a DHCPv6
! client should use when resolving hostnames with DNS. The primary
! function of the Domain Search List is to help clients find
! resources on a network by automatically appending domain
! suffixes to unqualified hostnames
domain-name 1 [Link]
exit
interface 10gei-1/1/0.1
mode relay
! The relay-agent address is used by the router to communicate
 ! with the DHCPv6 server when acting as a relay agent. It is
! typically the interface address on the relay-server side.
relay-agent 4444::1
relay-server-group myRelaySvr
! bind the address pool or pd pool as defined above
dhcp-pool myDHCPv6Pool
enable server-unicast
exit
relay-server-group myRelaySvr
algorithm normal
max-retry 3
server 1 4444::2
exit

4.​ Configure address pool and PD pool

ippoolv6 delegation-pool ipoe_ipv6_del_pool
dns-primary 2001:4860:4860::8888 secondary 2001:4860:4860::8844
prefix-address 2804:3ef0:e101:: prefix-length 48 delegation-length 64
! reserved-prefix start-pd-address 2804:3ef0:e101:1:: end-pd-address
2804:3ef0:e101:ff:: ! optionally reserve prefix
pool-status unlock
warning-threshold 80
warning-exhaust disable
exit

ippoolv6 addr-pool ipoe_ipv6_addr_pool​

dns-primary 2001:4860:4860::8888 secondary 2001:4860:4860::8844
pool-status unlock
warning-threshold 80
warning-exhaust disable
addr-range start-ipv6-ip 2804:3ef0:e100::2 end-ipv6-ip
2804:3ef0:e100::ffff
exit
exit

ippoolv6 prefix-pool ipoe_ipv6_prefix_pool

prefix-address 2a00:54e0:900:: prefix-length 64
dns-primary 2a00:54e0::d0d0 secondary 2a00:54e0::d0d1
pool-status unlock
assign-mode eui-64 ! important to set assign mode to eui-64 for SLAAC
calc-mode Byte ! set to bit if prefix length is not multiple of 8
exit
​
NOTE about IPv6 pool definitions:
●​ Note the differences in the three different IPv6 pools you can define on the router:
○​ Address pool is used for stateful IPv6 address allocations for the CPE WAN
interfaces connected to the BNG router.
 ○​ Prefix pool is used for stateless (SLAAC) IPv6 address allocations for the CPE
WAN interfaces connected to the BNG router.
○​ PD pool is for allocating prefixes to the CPE devices from which the CPE device
will generate IPv6 addresses and assign them to the connected end devices.
●​ Make sure the address space defined in the PD pool is mutually exclusive from the address
space defined either in the address pool or in the prefix pool. A good practice is to assign a
/48 for the address or prefix pool and then another /48 for the PD pool
●​ In terms of DNS assignment to the subscribers:
○​ For stateful IP addresses allocation, the router will assign the subscriber the DNS
configured in the address pool, not the DNS configured under dhcpv6
○​ For slaac IP addresses allocation, the router will assign the subscriber the DNS
configured in the prefix pool.
○​ For PD allocation, the router will assign the subscriber the DNS configured in the
PD pool. Please note most CPEs can be configured to let PD inherit the DNS
setting on the CPE’s wan interfaces.
●​ In the prefix-pool definition, make sure assign-mode is set to eui-64. This gives
maximum compatibility with subscriber’s CPE routers.
●​ In the prefix-pool definition, set “calc-mode” to “Byte” if the prefix length aligns on byte
boundaries. Otherwise set it to “bit”. For example, if the prefix length is 52, you need to
set the “calc-mode” to “bit”
●​ In the PD pool definition, try to make delegation-length 64. This will give the widest
compatibility to subscriber’s end devices. For example, some versions of MS Windows
only accept 64 bit prefixes. If you set prefix-length to 48 and delegation-length to
64, the BNG router can give 2^(64-48) = 65536 PD prefixed to connected CPE devices.
●​ In the PD pool definition, you have to use reserved-prefix to reserve PD prefixes as
shown in the above PD pool example if you are going to assign PD prefix from radius with
the public attribute Delegated-IPv6-Prefix.​

5.​ Define access domain and bind the ipv6 ip pools to the domain​

domain my_domain
bind authentication-template radius_auth_tmpl
bind accounting-template radius_acct_tmpl
bind authorization-template radius_auth_tmpl
bind-delegation-pool ipoe_ipv6_del_pool
bind-addr-pool ipoe_ipv6_addr_poolvc
bind-prefix-pool ipoe_ipv6_prefix_pool
vgi vgi1
domain-status unlock
user-routing-distribute disable
tunnel-domain disable
flow-statistic enable
radius-attribute qos-acl-profile no-exist-policy offline
quota-out offline
bind-pool 1 ipoe_ipv4_pool
exit
​
NOTE: From version 1.7.33.B10P2 and onwards, the router supports domain binding to both
 “regular” prefix pool and “prefix delegation style” prefix pool. The previous version only supports
domain binding for “regular” prefix pool as shown above.
●​ “regular” prefix pool: the regular prefix pool only has one prefix. All subscribers will get the
same prefix and subscribers generate their own IPv6 address based on the same prefix. To
bind a regular prefix pool, use the command ​
“bind-prefix prefix-pool-name ipoe_ipv6_prefix_pool”
●​ “prefix delegation style” prefix pool: the prefix delegation style prefix pool has many
prefixes. Each subscriber will get its unique prefix and generate its ownIPv6 address based
on its unique prefix. netElastic’s vBNG router uses the prefix delegation pool definition for
this type of prefix pool. To bind a prefix delegation stype prefix pool, use the following
command. ​
“bind-prefix delegation-pool-name ipoe_ipv6_del_pool”​
Here, the pool “ipoe_ipv6_del_pool” is really used as a prefix pool although it is defined
as a delegation pool. If you are using a prefix pool in this manner and a pd pool at the same
time, you need to define two prefix delegation pools. One for prefix delegation and the other
for prefix address allocation for the CPE WAN interface.

6.​ Enable dual stack is on vci interfaces and bind ipoe domains for ipv4 and ipv6
bras
vci-configuration
interface 10gei-1/1/0.750
ipoe template my_ipoe_template ! specify ipoe template
pppox template my_pppoe_template ! specify pppoe template
max-ipox-session 32000
max-pppox-session 32000
encapsulation multi
pre-domain ​ my_domain ! specify v4 domain for ipoe
v6pre-domain my_domain ! specify v6 domain for ipoe
ip-access-type dual
exit
exit
exit

7.​ Configure related routes so the IPv6 traffic can come in and out the router per routing policy. ​
The routing rules can be accomplished either by static route configuration or by running IPv6
dynamic routing protocols with peering routers. See the router configuration for more information

All other configurations such as AAA templates, etc. should be the same as the IPv4 access
configurations.

IPv4/IPv6 Dual Stack Troubleshooting

To debug and check IPv6 dual stack IPv6 assignment and routing, please follow these steps:
●​ It is important to note that dhcpv6 configuration on all relevant interfaces are essential for PD and
stateful WAN IP assignment. Even if you don’t care about stateful CPE WAN IP assignment, you
still need to configure dhcpv6 for PD assignment to work.
●​ From the router do a ping test to an external public IPv6 address such as Google’s public IPv6
DNS. e.g. “ping 2001:4860:4860::8888”. Make sure the ping can go through. If the ping
test does not go through, check the WAN interface IPv6 configuration and IPv6 routes on the
router.
●​ Use the command “show route ipv6 database” to display the IPv6 routing table if IPv6
routing issues are suspected.
●​ Use the command “show smgr-session detail by-user-name [user name]” to display
user smgr session details where the user's IPv6 address, DNS, and PD assignment will be
displayed if assignments were successful.
●​ Use the command “show smgr-session summary” to check how many users have the
“DUAL” access type and also pay attention to how many actually get IPv6 addresses. You can
use the command “show smgr-session detail user info ip-access-type | select
info user-name | include dual-stack” to display the users whose access type is
“DUAL”. Then you can pick a user and drill down the user by listing the user’s smgr-session
details or examine its access logs to debug further.
●​ Even if a user’s ip-access-type is DUAL, it does not necessarily mean it will get an IPv6 address
because there might be other factors preventing the user from successfully getting an IPv6
address. Use the command “show smgr-session summary detail full_in_dual” to
display the actual number of users who actually get IPv6 addresses. Use the command “show
dhcpv6 user-detail | include client-mac” to list the mac address of the users who
actually get IPv6 addresses. Then you can use the command “show smgr-session detail
by-mac-address xx:xx:xx:xx:xx:xx” to display the user access details to examine its
IPv6 related information.
●​ If subscriber can not connect successfully to get dhcpv6 addresses, please check the ndp log
(/var/log/certus/ndp) and dhcpv6 log (/var/log/certus/dhcpv6).The logs carry
important dhcpv6 online process protocol exchanges messages.
●​ If the subscriber can only get PD, but not WAN IP or the other way around, check the dhcpv6 log
and search for the keyword ‘address type” (e.g. use the command. grep ‘address type”
/var/log/certus/dhcpv6) to make sure the addresses requested by the cpe match your
expectation. The possible values for address type are
○​ pd - CPE requested only PD
○​ address - CPE requested only stateful WAN IP
○​ address&pd - CPE requested both stateful WAN IP and PD
●​ If the subscriber can get an IPv6 WAN address and PD prefix, but the traffic does not flow end to
end, check the routing table on the router to ensure there are user routing entries for both the
CPE wan IP and PD prefix. For example, if the CPE gets WAN IP
2403:4840:2000:0:7ea9:6bff:fe07:c77b and PD 2403:4840:2001:93::/64. You can look up the
route to the PD on the route as shown below where it properly shows that to reach the PD prefix,
the router will go through the CPE WAN IP by subscribers’ access interface vgi1
dwan_vbng# show route ipv6 2403:4840:2001:93::/64
Routing entry for 2407:4840:2001:93::/64
Known via "unr", distance 10, metric 10, best
Last update 00:00:04 ago
* via 2403:4840:2000:0:7ea9:6bff:fe07:c77b, vgi1
 ●​ For an IPoE HA setup, if the IPv6 stack ends up on a different instance from the one where the
IPv4 stack is, you can configure the IPv6 stack to be dependent on the IPv4 stack. This means
that IPv6 will only come online if IPv4 is already online. If the IPv4 stack goes offline, the
corresponding IPv6 stack will be automatically cleared. This ensures that the IPv6 stack
consistently mirrors the state of the IPv4 stack. To enable this feature, use the following
configuration: ​
bras -> ipoe template [ipoe template] -> dhcp-v6 auth-on-up mode on-IPv4
●​ After the subscriber’s end device gets IPv6 addresses, you can do an ultimate IPv6 test by trying
to visit an IPv6 test site such as [Link]

IGMP/PIM Configurations
netElastic vBNG routers support IGMP protocol that allows subscribers to join multicast groups. The
supported feature include
●​ IGMP v1/v2/v3
●​ PIM-SM and PIM-SSM
●​ Multicast VLAN

IGMP Configuration
The following is a typical IGMP configuration and its application to subscribers.

! enable ip multicast routing on the router

ip multicast-routing

! configure igmp routing

router igmp
interface 10gei-1/1/1
enable ! enable igmp on this interface
! configure immediate leave. when configured, when igmp receives
! the leave message, it will immediately delete the member without
! looking up the client from the multicast group.
! using this command is inconsequential, as the current router
! version only support static igmp
immediate-leave
! configure static igmp group
static-group [Link] *
exit
! configure more static igmp group
static-group [Link] *
exit
exit
exit

! configure pim routing for ipv4 address family

router pim address-family ipv4
 ! specify RP (Rendezvous Point). All routers in the same PIM-SM domain
! need to be configured with the same RP
static-rp ipv4-rp [Link]
! set to let static RP to overrides dynamically learned RP
sm override true
exit
exit

! add the relevant interfaces to pim routing.

router pim interface 10gei-1/1/0
address-family ipv4
! enable pim sim for this interface
sm
exit
exit
router pim interface 10gei-1/1/1
address-family ipv4
! eanble pim sim for this interface
sm
exit
exit

! define umgmd profile and specify the multicast groups.

bras
umgmd profile my-igmp
static-group [Link]
static-group [Link]
exit
exit

! finally bind the umgmd profile in the subscribers authorization domain

bras
authorization myAuthorization
authorization-type mix-radius
igmp my-igmp
nat-type none
radius-nat-switch disable
exit
exit

IGMP Troubleshooting
The following commands are for showing IGMP status and troubleshooting
●​ show ip igmp groups​
display igmp group member status
●​ show ip igmp interface ​ ​
display igmp interface status
 ●​ show ip pim interface​
display IP PIM enabled interface status
●​ show ip pim mrouter​
display igmp multicast routing information
●​ show ip pim neighbor​
display IP PIM enabled interface neighbour information
●​ show ip pim rp​
display ip pim rp (rendezvous point) information

Router Configurations
Often vBNG routers are connected to upstream core routes so user traffic can be routed to the internet
and vice versa. vBNG needs to exchange routes with its upstream core routers. This can be achieved by
configuring Static, OSPF, or BGP routing functions on the vBNG router.

General Router Debug Tips

Here are some commonly used router related troubleshooting tips:
●​ To show the chosen route the vBNG router will take to reach a destination, use the command
“show route [ip-address]”. This command is very useful in troubleshooting routing
problems on the router. It literally displays what interface and next hop the router will take to
reach the tested ip based on the routing table currently loaded on the router.
●​ If strange routing behaviors are observed such as you can not even ping connected next hop,
check the following
○​ make sure all the router processes are running. you can check the router running status
by the command “flexbng” in Linux
○​ make sure route size is within the license route limit. To check the current route table
size, use the command “show router summary” to display the current various route
sizes and installed FIB table size. If the total route size is larger than the installed FIB
table size, it most likely means the routes on the router have exceeded the licensed route
capacity. To check the license specification for the routing table size, use the command
“show license specification”
●​ To display all routes, use the command “show route database”. To display only connected
routes, use the command “show route connected”. To display only static routes, use the
command “show route static”. To display all bgp routes, use the command “show route
bgp”. To display all ospf routes, use the command “show route ospf”.
●​ If the router does strange things and seems to not follow the routing table as seen in the control
plane, you can login to the DP and check routes as seen by DP FIB. Here is how:
○​ login to DP by “telnet 0 5002” from the router host Linux.
○​ use command “show ip route [dest ip address]” (e.g show ip route
[Link]) to display the route to the destination IP as looked up by the DP FIB.
Static Routes
With static route configuration, you can specify default routes and prefix based static routes. With static
route configuration, you can use the combination of interface and next hop IP to specify the exit interface.
Here are some examples:

! use static route to specify default route by interface and next hop IP
router static
ip route [Link] [Link] ifname-nexthop 10gei-1/1/1.1902 [Link]​
ipv6 route :: 0 ifname-nexthop 10gei-1/1/1.1902 2001:2304:1234::2
exit

! use static route to specify two default routes with different distance
! the route with a smaller distance metric will be the preferred route.
router static
ip route [Link] [Link] nexthop [Link] distance 20
ip route [Link] [Link] nexthop [Link] distance 30
exit

! use static route to specify the next hop IP for certain prefixes.
router static
ip route [Link] [Link] nexthop [Link]
exit

! use static route to specify the next hop IPs for certain prefixes.
! with different distance metrics (smaller distance route is preferred route)
router static
ip route [Link] [Link] nexthop [Link] distance 20
ip route [Link] [Link] nexthop [Link] distance 30
exit

! use static route to specify certain prefixes to blackhole.

router static
ip route [Link] [Link] ifname null0
ip route [Link] [Link] ifname null0
exit

OSPF
OSPF works on direct L2 connected routers. vBNG will negotiate with L2 connected neighboring routers,
discover each other, and exchange/distribute routes based on the OSPF router configuration. Eventually
all the routers in the same OSPF area will achieve the full state where all of participating routers share the
same routing database.

Multiple OSPF instances can be created on the router.

OSPF Example - V4
Here is an example of an OSPF configuration example. In this example, you have two interfaces
through which the OSPF router will be establishing neighbors with. It is configured to advertise
network [Link]/30 and network [Link]/30, in addition to advertise
connected, nat, and unr routes.

router ospf instance 6

router-id [Link]
area [Link]
authentication-mode null
exit
interface eth-trunk1.100 ! ospf interface
exit
interface eth-trunk1.600 ! ospf interface
network point-to-point
cost​ 10
authentication-mode null
exit
network [Link]/30 area [Link] ! distribute network of the inf
network [Link]/30 area [Link] ! distribute network of the inf
default-information originate always ! always send default route
redistribute connected ! distribute connected routes​
passive-interface loopback0 ! distribute passive inf routes
summary-address [Link]/27 ! e.g summarize user routes
summary-address [Link]/30 ! e.g summarize nat routes
redistribute nat ! distribute nat routes
redistribute unr ! distribute user routes
redistribute static ! distribute static
exit

Some commonly used OSPF v4 configurations:

●​ network [network] area [area]: distribute specified network to the specified area.
●​ redistribute connected/static/nat/unr: redistribute connected routes, static routes,
nat routes, user routes
●​ default-information originate always: always distribute default route regardless if
the default route exists or not on the router.
●​ passive-interface [interface]: distribute passive interface routes. This means
distributing the routes associated with the interface, but the interface itself does not participate
in the running of OSPF.

OSPF Example - V6
Here is an example of an OSPF V6 configuration example. In this example, you have two interfaces
through which the OSPF router will be establishing neighbors with. It is configured to advertise
network 2605:2540:2::/48 and network 2605:2540:3::/48, in addition to advertise connected, static,
 and unr routes. Keep in mind that participating interfaces for ospf v6 need to have IPv6 address
assigned and ipv6 enabled. The relevant IPv6 interface configuration is also shown in the example.

! ospf v6 sample configuration

router ospfv3 instance 0
router-id [Link]
summary-prefix 2605:2540:2::/48
summary-prefix 2605:2540:3::/48
redistribute connected
redistribute static
redistribute unr
area [Link]
interface 25gei-1/1/2 instance 0
cost​ 10
network point-to-point
exit
interface loopback0 instance 0
passive
exit
exit
exit

! ospf interface configuration

interface 25gei-1/1/2
description "Network Port"
ipv4 address [Link] 30
ipv6 enable
ipv6 address 2605:2540:0:22b::2 126
exit

OSPF Route Filtering - Example 1

Here is an example of an OSPF configuration example with route filtering. You can achieve this by
using an access list. The following is an example of OSPF with incoming and outgoing router filters
by access list. Note: for outgoing route filters, the filter applies after a particular local route category
such as nat, connected, unr etc. You can have multiple in and out route filters applied to OSPF.

! define ospf filter in the out direction to only allow certain prefix to go out
access-list ospf-out
rule 10 permit ip source [Link]/24 destination any
rule 20 deny ip source any destination any
exit

! define ospf filter in the in direction to only allow route [Link]/22

! and deny others
access-list ospf-in
rule 10 deny ip source [Link]/22 destination any
rule 100 permit ip source any destination any
exit

! if you want to deny all routes but only install default route
 ! the ospf route filter can be configured like the following.
access-list ospf-in-accept-default-only
rule 10 permit ip source [Link]/0 destination any
rule 20 deny ip source any destination any
exit

router ospf instance 6

router-id [Link]
area [Link]
authentication-mode null
exit
distribute-list in ospf-in
distribute-list in ospf-in-accept-default-only
distribute-list out connected ospf-out
distribute-list out nat ospf-out
interface 10gei-1/1/2
exit
interface 10gei-1/1/3
exit
network [Link]/30 area [Link]
network [Link]/30 area [Link]
redistribute connected ! redistribute connected routes
redistribute nat ! redistribute nat routes
redistribute unr ! redistribute user routes
exit

OSPF Route Filtering - Example 2

Here is another example of an OSPF configuration example with route filtering. In this example, we
will use a route filter to filter all private /32 from a /16 space from being advertised. We can not use
access-list as access-list can only specify fixed subnets. In this case, we need to filter out all /32 user
routes in the whole /16 subnet space. We will achieve this objective by using prefix list as shown in
the following configuration

! define a prefix list to identify routes from /16 to /32

prefix-list ospf-filter-list 1 permit [Link] 16 le 32

! create a router map that denies the prefix list

route-map ospf-router-map 1
action deny
match ip address prefix-list ospf-filter-list
exit

router ospf instance 0

router-id [Link]
area [Link]
authentication-mode null
exit
interface eth-trunk1.3025
network ​point-to-point
cost ​10
retransmit-interval 5
 transmit-delay ​1
hello-interval ​10
exit
network [Link]/30 area [Link]
network [Link]/30 area [Link]
redistribute connected
redistribute nat
redistribute static
! apply the router map to unr routes
redistribute unr route-map ospf-router-map
exit

OSPF Route Advertise Tips

●​ To advertise user routes without using “user-routing-distribute” to enable individual user
routes, you can use summary-address such as “summary-address [Link]/20”
●​ To advertise routes assigned with an interface without using that interface to run ospf, you can
use the “passive-interface” statement such as “passive-interface vgi1”, which will
advertise the network associated with vgi1.

OSPF Troubleshooting
●​ Use the command “show ospf-state neighbor all” to check the OSFP status. If no OSPF
hello messages are received from the router, it indicates that that configuration is not valid.
Please check
○​ Make sure that there is a corresponding network statement configured for each
participating interface. The CIDR network notation should represent the network in which
the participating interface is. For example, if the OSPF participating interface 10gei-1/1/0
has IP [Link]/30 on it, you need to add network [Link]/30 area [Link] in
the configuration.
○​ Make sure the peering interfaces can ping each other to prove out connectivity.
●​ If OSPF neighbourship can not be established, check the following:
○​ Check the area ID match between the router instance and its neighbor.
○​ Check the MTU setting to make sure they match between neighbors.
○​ Under each interface, make sure that the network type setting (broadcast/unicast) match
that of the peering router.
○​ check the ospf logs for error and warning messages. The ospf logs are located
■​ /var/log/certus/ospfd - ospf logs for ipv4
■​ /var/log/certus/ospf6d - ospf logs for ipv6
●​ When using summary-address, you have to ensure
○​ part of the summary-address is in the router’s routing table (e.g. connected, static, etc)
○​ you must be advertising part of the summary-address such as through
“user-routing-distribute”
●​ Commonly used OSPF commands
○​ To reset/clear OSPF​
clear-ospf-process
 ○​ To show ospf neighbor status​
show ospf-state neighbor all
○​ To show ospf route summary ​
show ospf-state database summary all
○​ To show ospf routes processed by osfp engine​
show ospf-state database all
○​ To show ospf routes actually installed on the router​
show route ospf

BGP
BGP works on L3 connected routers. vBNG will negotiate with BGP neighboring routers, discover each
other, and exchange/distribute routes based on the BGP router configuration. Unlike OSFP, BGP does
not require direct L2 connections and can establish routing neighbors across networks. Often you will see
BGP runs on top of OSPF. OSPF takes care of the L2 topology and establishes underlying routes so the
BGP can communicate with its peers via the routes established by OSPF. If vBNG has direct L2
connections with upstream core routers, running just OSPF is sufficient in terms of route exchange
between the vBNG and upstream routers. Running BGP on top of OSPF is optional in this case.

Only one BGP instance can be created on the router.

Sample BGP Configuration Overview

Here is a sample BGP configuration:

router bgp 138523

router-id [Link]
! optional confederation configurations
confederation identifier 65000
confederation member-as 65002 65003
! ipv6 address family
address-family ipv6-unicast
network-v6 2404:2640:4001:500::/64
aggregate-address 2404:2640:4000::/36
summary-only
exit
exit
! ipv4 address family
address-family ipv4-unicast
redistribute connected
redistribute static
redistribute unr
redistribute nat
aggregate-address [Link]/24 ! advertise the whole /24 route.
summary-only
exit
exit
neighbor [Link]
update-source 10gei-1/1/1.213
remote-as 58656
address-family ipv4-unicast
next-hop-self ! specify the router itself as the out routes’ next hop
exit
 exit
neighbor [Link]
update-source 10gei-1/1/1.210
remote-as 58656
local-as 138523
address-family ipv4-unicast
soft-reconfiguration-inbound
exit
exit
neighbor 2404:d900:6000:3c::1
update-source 10gei-1/1/1.210
remote-as 58656
address-family ipv6-unicast
soft-reconfiguration-inbound
exit
exit
exit

Notes about the above configuration:

●​ BGP configuration needs to have AS number, router ID, which is usually the ip address of an
interface of the router such as loopback.
●​ The optional BGP confederation configuration allows you to scale your iBGP network better.
For detailed instructions and examples, please refer to the Using BGP Confederation section.
●​ BGP configuration needs to have address-family ipv4-unicast or/and address-family
ipv6-unicast defined to specify what type of routes under which to advertise. The
address-family ipv4-unicast or/and address-family ipv6-unicast configurations
declare the BGP instances’s capabilities and need to be there for the router to establish
neighborhood with peering routers. If you have no routes to advertise, you still need to have
these statements configured without putting any route advertise rules inside.
●​ BGP configuration needs to have neighbors with their IP and AS number defined. Under each
neighbor, you need to have
○​ update-source: This needs to be set to the interface where the BGP instance
router-id IP is configured. For example, if the router-id IP is on a physical interface,
update-source needs to be set to that physical interface. If the router-id IP is on a
logic interface such as loopback0, update-source needs to be set to that logical
interface as well.
○​ remote-as: remote peer BGP as number.
○​ address-family ipv4-unicast or/and address-family ipv6-unicast: This needs
to be defined to specify the type of routes that router will exchange with that neighbor.
Like stated above, statements address-family ipv4-unicast or/and address-family
ipv6-unicast need to be configured for each neighbor regardless of whether you have
routes to exchange with that neighbor or not. Otherwise, the neighborhood won’t be
established with that neighbor. ​
Under each neighbor’s address family, you can optionally configure next-hop-self if
you need to specify the router itself as the next hop for the advertised routes.
●​ Configure “soft-reconfiguration-inbound” under a neighbor’s address-family (v4 or v6) to
enable soft route update from this neighbor. Without this configuration, the only time that the
whole route is updated from this neighbor is when the neighbourship with this neighbor was first
established. To get the full route from this neighbor, you have to tear down the bgp link down
 with this neighbor and establish again. With this configuration in place, you can force a route
update from this neighbor with the command such as “clear-bgp all in ipv4-unicast”

Advertise routes to neighbors

IPv4 and IPv6 routes that need to be advertised to neighbors need to be specified under the
respective address families such as “address-family ipv4-unicast” and “address-family
ipv6-unicast” etc in the bgp global configuration section. The support address families are:
●​ ipv4-unicast
●​ ipv6-unicast
●​ ipv6-labelled-unicast
●​ l3vpn-ipv4-unicast
●​ l3vpn-ipv6-unicast

Under each neighbor, address families such as “address-family ipv4-unicast” must be

configured for each neighbor so the router can establish neighborship with this neighbor.
“address-family ipv6-unicast” needs to be configured under a neighbor if IPv6 routes need to
be advertised to this neighbor. For example, if you have networks defined under “address-family
ipv6-unicast” in the bgp global configuration section, but don’t have “address-family
ipv6-unicast” defined under a particular neighbor, IPv6 routes won’t be able to sent to this
neighbor.

To show routes advertised to a particular neighbor, use this command as shown in this example:​
show bgp neighbor-route all default [Link] advertise

Type of routes that could be advertised

The common types of routes that could be automatically advertised to the neighbors are:
●​ connected routes - use “redistribute connected [route-map]” to redistribute
●​ isis routes - use “redistribute isis[route-map]” to redistribute
●​ nat routes - use “redistribute nat [route-map]” to redistribute
●​ ospf routes - use “redistribute ospf [route-map]” to redistribute
●​ ospf v3 routes - use “redistribute ospfv3 [route-map]” to redistribute
●​ static routes - use “redistribute static [route-map]” to redistribute
●​ user routes - use “redistribute unr [route-map]” to redistribute​
Note: to successfully redistribute unr, the user routes have to be present in the router's routing
table first. You can enable /32 user router generation by setting “user-routing-distribute
enable” in the user’s access domain definition.
●​ singular routes - use “network” to specify singular routes that exist on the router as shown in
the following example.
●​ aggregate routes - user “aggregate” to define aggregate routes that combine smaller routes
into larger routes and redistribute only the aggregated routes as shown in the following
example.
●​ default route - use “default-originate” to advertise default route to a neighbor. This can
only be used under a neighbor.

NOTE: In most of the types listed above, you can use the optional “[route-map]” to select a subset
of routes that you want to be distributed.
Routes need to be made to the router’s BGP table before it can be advertised out. Along the way,
there are several ways by which you can control what routes to advertise. It is important to
understand how routes are advertised from the router. They go through the following steps:
●​ Raw routes on the router. They can be nat, connected, default, static, or received routes etc.
Regardless of route types, they first have to exist on the router in whole or partial (ref
aggregate address case) before they can be advertised out.
●​ Under each neighbor you have to configure “address-family ipv4-unicast” and/or
“address-family ipv6-unicast” sections for IPv4 and/or IPv6 routes to be advertised to
this neighbor. For example, if you want to prevent IPv6 routes from being advertised to a
particular neighbor, you can do so simply by not configuring the “address-family
ipv6-unicast” section under this neighbor.
●​ Pick what type of routes to be advertised with an optional [route-map] filter to selectively
choose what routes to advertise.
●​ Optionally you can aggregate routes with the aggregate-address/summary-only
statement. This is especially useful when dealing with a lot of smaller routes. For example, if
you choose to redistribute nat, the router could possibly create many smaller routes
including /32 routes to cover the whole IP section you defined under nat -> ippool
group. You can use aggregate-address/summary-only to aggregate them into one
bigger non-fragmented network.
●​ At the end of the above steps, the routes passing through the filters will be available to be
advertised to all neighbors. Next, at each individual neighbor level, you can use in and out
route map filters to selectively choose what routes to receive and what routes to go out to this
neighbor.

Depending on whether the advertised route existed on the vBNG router’s routing table or not, routes
are advertised differently.

Advertise routes that exist on the vBNG Router

If a route exists in the router’s routing table as displayed with the “show route database”, you can
advertise these routes with the network or network-v6 statement as shown in the following
examples.

router bgp 138523

router-id [Link]
address-family ipv6-unicast
network-v6 2404:2640:4000::/36
exit
address-family ipv4-unicast
redistribute nat
network [Link]/24
exit
exit

Advertise routes that do not all exist on the vBNG Router

If only part of a route exists on the router’s routing table, but the whole route does not explicitly exist
on the router’s routing table, you can not use network or network-v6 statements to advertise these
routes as the route itself in its entirety does not exist in the router’s routing table. For example, you
may have a few users from [Link]/24 online with /32 routes, but you want to advertise the
whole /24 to the peering router. You can solve this by one of the following two ways:
●​ Create a route entry for the route you want to advertise so that it can come into existence on the
router's routing table and then advertise the route with the network statement as shown above.
For example, we can create a static route [Link]/24 and point it to the null0 interface,
and then the route [Link]/24 will exist as a static route on the router. You shall then be
able to use the statement network [Link]/24 to advertise this route out. Note, in this
example, even static route [Link]/24 is pointing to null0, it won’t affect the user router
since the users have /32 routes which will take precedence over [Link]/24.
●​ Use the “aggregate-address” statement to advertise these routes. For example, you only have
some /31, /30 routes on your router, but your peering router only accepts /24 routes, then you can
use the aggregated route of these fragmented routes to advertise to the neighbors. Here is an
example:
router bgp 138523
router-id [Link]
address-family ipv6-unicast
network-v6 2404:2640:4001:500::/64
aggregate-address 2404:2640:4000::/36
summary-only
exit
exit
address-family ipv4-unicast
redistribute nat
aggregate-address [Link]/24
summary-only
exit
exit
exit

NOTE on aggregate address:

Please note that aggregate happens after the type of routes you specified to advertise. For
example, you need to aggregate nat route, you have to specify redistribute nat first. as
shown in the above example.

Advertise VRF/L3VPN routes

To advertise VRF/L3VPN routers you need to:
1.​ specify address-family l3vpn-ipv4-unicast in the bgp global configuration
2.​ specify address-family l3vpn-ipv4-unicast under the relevant BGP neighbor configuration, and
include the send-community both as highlighted in the following example.

router bgp 12345

router-id ​ [Link]
log-neighbor-change
 graceful-restart enable
! specify l3vpn ipv4 family in the bgp global configuration
address-family l3vpn-ipv4-unicast
exit
address-family ipv4-unicast
exit
! importing directly connected routes from the local VRF into BGP
vrf vBNG
address-family ipv4-unicast
redistribute connected
exit
exit
neighbor [Link]
description HSTNRDC04 Route Reflector
update-source loopback0
remote-as 54321
! specify l3vpn ipv4 family for this neighbour
address-family l3vpn-ipv4-unicast
send-community BOTH
exit
exit
exit

Add Route-map Filter to control BGP advertise/receive lists

Filtering receiving or advertising routes can be done either with an access list, route map prefix filter,
or a combination of both.

●​ prefix-list - can be defined to permit or deny routes based on network prefix definitions.
●​ route-map - In addition to permit or deny routes based on network prefixes (when used with
prefix-list), it can also be configured to permit or deny routes based on as-path, community,
interface, metric, route-type, etc.
.
The route filters (prefix-list or router-map) can be applied
●​ either globally under the type of routes redistributed so the rules apply to all neighbors
●​ or apply under a neighbor so the rule is only applicable to that neighbor. When applied under a
neighbor, you can use the following states to control route advertise/receive filtering.
○​ in distribute-list [access list] - filter incoming routes with access list
○​ in prefix-list [prefix list] - filter incoming routes with prefix list
○​ out distribute-list [access list] - filter outgoing routes with access list
○​ out prefix-list [prefix list] - filter outgoing routes with prefix list
○​ route-map [route map] in - filter incoming routes with route map
○​ route-map [route map] out- filter outgoing routes with route map

Please note that route-map filters can contain multiple matching rules. For each route, the evaluation
begins with the rule that has the lowest rule number and continues sequentially until a permit or deny
action is encountered. As a result, not all rules in a route-map filter are necessarily evaluated.
Take the follow route-map filter for example
 ! this rule permit prefix define in prefix list netElastic-PUBLIC
! to pass, not matched prefix will be denied
route-map TO-RR-OUT 10
action permit
match ip address prefix-list netElastic-PUBLIC
exit
! this rule set all routes with the configured community string
route-map TO-RR-OUT 20​
action permit
set community non-none comm-number [ 13836:15110 ]
exit
For routes that match rule 10, the action in rule 20 will not be applied, as a match in rule 10 results in
a definitive permit action. This causes the route-map evaluation to exit, and rule 20 will not be
processed for these routes. If you intend to apply the above-mentioned community string to matching
routes, you should combine the match statement and the set statement in a single route-map rule, as
shown below.
! this rule permit prefix define in prefix list netElastic-PUBLIC
! AND set matching routes with the configured community string
route-map TO-RR-OUT 10​
action permit
match ip address prefix-list netElastic-PUBLIC
set community non-none comm-number [ 13836:15110 ]
exit

Route map filter can be used in conjunction with the redistribute statement to further filter routes
advertised by the router. You can also use route map filters to set community strings for outgoing
routes as shown in the following example.

We will illustrate the usage of route-map filter with a few examples:

Example 1: Use route filter on incoming and outgoing routes

! define a prefix list

prefix-list netElastic-PUBLIC-LOCAL 40 permit [Link] 28 le 32
prefix-list netElastic-PUBLIC-LOCAL 50 permit [Link] 24 le 32

! define a route-map so only routes match these will be advertised

route-map REDIS-CON 10
action permit
match ip address prefix-list netElastic-PUBLIC-LOCAL
exit

! define route map to control what routes to go out and also can
! set community string for these routes
route-map TO-RR-OUT 10
action permit
match ip address prefix-list netElastic-PUBLIC-LOCAL
 set community non-none comm-number [ 20205:9001 ]
exit

! define prefix list for default routes

prefix-list DEFAULT 10 permit [Link] 0
! define prefix list for rejecting this subnet
prefix-list TEST-REJECT 10 permit [Link] 24

route-map FROM-RR-IN 5
action deny
match ip address prefix-list TEST-REJECT !reject this route
exit
route-map FROM-RR-IN 10
action permit
match ip address prefix-list DEFAULT !accept default route
exit
route-map FROM-RR-IN 20
action permit
match community exact-enable standard comm-number [ 20205:9000 ]
exit

route-map REDIS-NAT 10
action permit
match ip address prefix-list netElastic-PUBLIC-LOCAL
exit

router bgp 20205

router-id [Link]
address-family ipv4-unicast
redistribute connected route-map REDIS-CON !redis connected with filter
redistribute nat route-map REDIS-NAT !redis nat with filter
aggregate-address [Link]/30 !aggregate distributed nat routes
summary-only
exit
aggregate-address [Link]/24 !aggregate connected routes
summary-only
exit
exit
neighbor [Link]
update-source loopback0
remote-as 20205
address-family ipv4-unicast
soft-reconfiguration-inbound
send-community ​ STANDARD !required for sending community
next-hop-self
route-map FROM-RR-IN in !control what routes to take
route-map TO-RR-OUT out !control what routes to go out
exit
exit
exit
Example 2: Use access list to filter incoming routes

neighbor [Link]
update-source loopback1
remote-as 65001
address-family ipv4-unicast
in distribute-list bgp_route_filter
exit
exit
access-list bgp_route_filter
rule 10 permit ip source [Link]/24 destination any
exit

Example 3: Use route map filter to only accept the default route
In this example, we will set up a router map filter to only accept the default route from a bgp neighbor.

! define a prefix list to only accept default router and deny others
prefix-list my-prefix-list 1 permit [Link] 0 ​
prefix-list my-prefix-list 2 deny any ​

! create a route map based on the prefix list defined

route-map my-route-map 1
action permit
match ip address prefix-list my-prefix-list
exit

! apply route-map on the bgp neighbor in the IN direction

router bgp 204488
default-ipv4-unicast
address-family ipv4-unicast
redistribute connected
redistribute static
redistribute unr
redistribute nat
exit
neighbor [Link]
timers keepalive-interval 60 hold-time 180
remote-as 204488
override-capability
address-family ipv4-unicast
soft-reconfiguration-inbound
route-map my-route-map in
exit
exit
exit
Example 4: Use prefix-list route map to filter outgoing routes

prefix-list pl-fabric-out 10 permit [Link] 24 ge 25 le 32

prefix-list pl-fabric-out 20 permit [Link] 24 ge 25 le 32
prefix-list pl-fabric-out 30 permit [Link] 24 ge 25 le 32
prefix-list pl-fabric-out 40 permit [Link] 24 ge 25 le 32

route-map rm-fabric-out 10
action permit
match ip address prefix-list pl-fabric-out
exit

router bgp 204488

default-ipv4-unicast
address-family ipv4-unicast
redistribute connected
redistribute static
redistribute unr
redistribute nat
exit
neighbor [Link]
timers keepalive-interval 60 hold-time 180
description cr01.bcneq01
remote-as 204488
override-capability
address-family ipv4-unicast
soft-reconfiguration-inbound
route-map rm-fabric-out out
exit
exit
exit

In the above example, “prefix-list pl-fabric-out 10 permit [Link] 24 ge 25

le 32” means the prefix list filter pl-fabric-out will allow any of the prefixes
[Link]/24, [Link]/25, [Link]/26,..., [Link]/32 to
be advertised to any neighbors who use pl-fabric-out as route-map filer. Any routes defined
under the BGP’s address family (unr, nat, network, etc) will be advertised as long they can pass the
route-map filter defined.

NOTE on router map filter

●​ On making changes to route map rules with embedded prefix list or acl list:Our router does not
support dynamically updating routes when route-maps with embedded prefix-list rules have
changed. If you have made changes to a prefix list of acl list that is referenced by a route map
rule. You have to force-reset the route-map rule by removing and adding the rule again. For
example, if have make changes to the route map that is tied to disturbing connected routes as
shown in the first example, you have to do the following to reset the route map rule:
○​ Remove “redistribute connected route-map REDIS-CON” and commit
 ○​ Add “redistribute connected route-map REDIS-CON” back in and commit
This procedure is non-invasive and won’t affect neighboring states.
●​ When applying a prefix-list under a neighbor’s address-family, the filter won’t take effect until
either the neighbor is reset (clear-bgp neighbor [neighbor ip]) or clear bgp in
either the in or out directions (clear-bgp all in/out). The latter is a better option as it
only updates routes in the specified direction without bringing up/down the neighbors.

Example 5: Use aspath ACL to filter routes by AS numbers

If you need to limit incoming or outgoing routes based on AS numbers—in either direction—you can
do so as follows:
1.​ Define an aspath-access-list filter to specify which AS numbers to permit or deny. Each
rule has a unique numeric ID, and you can add multiple rules under a single
aspath-access-list filter.
2.​ Apply the filter to the relevant BGP neighbor’s address family using one of the following
methods:
a.​ Apply the aspath-access-list filter directly to the neighbor’s address family.
b.​ Create a route-map that references the aspath-access-list defined in step 1, and
apply the route-map to the neighbor’s address family.
In the following example, the BGP router is configured to only accept and advertise routes from
Google's AS on neighbor [Link]. Both methods described above are demonstrated.
! method 1: filter by as number with aspath ACL
router bgp 12345
aspath-access-list permitGoogle 1 permit 15169
neighbor [Link]
address-family ipv4-unicast
filter-list permitGoogle in
filter-list permitGoogle out
exit
exit
exit

! method 2: filter by as number with route-map

route-map RM-permitGoogle 10
action permit
match as-path permitGoogle
exit

router bgp 12345

aspath-access-list permitGoogle 1 permit 15169
neighbor [Link]
address-family ipv4-unicast
route-map RM-permitGoogle in
route-map RM-permitGoogle out
exit
exit
exit
Configure BGP Router as Route Reflector

Here is an example of configuring the router to be a router reflector, which redistributes learned
routes from other neighbors to the neighbor under which the router reflector is configured. To
configure the router to be a router reflector, you need to
1.​ set route-reflector-cluster-id (highlighted in red in the example). The value can be any
interface ip on the router as long as it does not conflict with other route reflect ID in the network.
2.​ set route-reflector-client (highlighted in yellow in the example) under the neighbor to
which you want the router to distribute the learned routes from other neighbors.

router bgp 42013

route-reflector-cluster-id [Link]
address-family ipv4-unicast
redistribute static
redistribute nat
exit
neighbor [Link]
remote-as 42013
override-capability
address-family ipv4-unicast
route-reflector-client
next-hop-self
nexthop-self-force
exit
exit
neighbor [Link]
remote-as 42013
override-capability
address-family ipv4-unicast
exit
exit
exit

Configure Both V4 and V6 Neighbours

Under the same BGP instance, you can have both V4 and V6 neighbors as shown in the following
examples.

router bgp 339014

router-id [Link]
vrf Carrier2
! v4 neighbor
neighbor [Link]
update-source 10gei-1/1/0.1404
remote-as 47662
! enable ipv4 route exchange for this neighbor
address-family ipv4-unicast
​ soft-reconfiguration-inbound
​ route-map bgp out
exit
exit
! v6 neighbor
 neighbor 2001:44f8:60:1::65
update-source 10gei-1/1/2.1403
remote-as 37704
! enable ipv6 route exchange for this neighbor
address-family ipv6-unicast
​ soft-reconfiguration-inbound
​ route-map bgp out
exit
exit
! enable ipv6 route exchange for this bgp instance
address-family ipv6-unicast
aggregate-address 2404:2640:4000::/36
summary-only
exit
exit
exit
! enable ipv4 route exchange for this bgp instance
address-family ipv4-unicast
redistribute nat
network 2d0f:5740::/32
exit
exit
exit

Here are some pointers when working with both V4 and V6 neighbors
●​ You first need to enable V4 or V6 or Both at the BGP instance level by specifying
“address-family ipv4-unicast” and “address-family ipv6-unicast” if you need
to exchange V4 or V6 routes with neighbors.
●​ You can exchange V4 or V6 or both routes with a V4 neighbor depending on the
“address-family” specification under each neighbor. If you only want to exchange V4
routes with a neighbor, just specify “address-family ipv4-unicast” under that
neighbor. If you want to exchange both V4 and V6 routes with a neighbor, you need to
specify “address-family ipv4-unicast” and “address-family ipv6-unicast”
under that neighbor. The same principle applies to V6 neighbors as well.

Configuring BGP under VRF

BGP can be configured under a VRF to achieve BGP route separation by VRFs. Here is an example
of eBGP configuration under a VRF.

! create VRF
l3vpn vrf CarrierB
exit

! bind VRF to relevant interfaces

interface 100gei-1/1/1.219
description “connection to provider B”
bind vrf CarrierB
nat outside
ipv4 address [Link] 30
dot1q 219
exit

! configure BGP and put neighbor and address families under VRF context
 router bgp 329104
vrf CarrierB
neighbor [Link]
update-source 100gei-1/1/1.219
remote-as 323987
address-family ipv4-unicast
soft-reconfiguration-inbound
default-originate
exit
exit
address-family ipv6-unicast
redistribute nat
network-v6 2001:45f8:1000::/48
network-v6 2c0f:5940::/32
exit
address-family ipv4-unicast
redistribute nat
network [Link]/23
exit
exit
exit

Notes about BGP when used under VRF:

●​ For versions prior to B4Px, due to a bug with BGP tcp connection under the context of VRF, the
BGP under VRF can only be configured as active/clientside when establishing TCP
connections with a neighbor. This means for versions prior to B4Px:
○​ The BGP will not work when peering with another netElastic router where BGP
is also configured under a VRF. Two netElastic routers can only peer with each
other if only one end is configured with VRF.
○​ When peering with routers from other vendors, make sure that the “passive”
key is not configured under that neighbor so the netElastic router won’t be forced
into a passive state.
●​ To display BGP summary under a VRF, use the command such as ​
show bgp summary vrf
●​ To display BGP neighbor status, use the command such as ​
show bgp neighbor [Link] CarrierB
●​ To display BGP neighbor routes under a VRF use the command such as ​
show bgp neighbor-route all CarrierB [Link] advertise

Using BGP Confederation

BGP confederation allows you to scale for large BGP networks which would require full-mesh iBGP
peering (every BGP router peering with every other). This doesn't scale well. BGP Confederation
addresses this by:
○​ Reducing the number of iBGP sessions.
○​ Allowing hierarchical internal routing.
○​ Making troubleshooting and policy management more modular.
 BGP confederation allows you to
○​ configure multiple sub-ASes inside a single AS.
○​ Routers within the same sub-AS use standard iBGP.
○​ Routers between sub-ASes use eBGP, but treat it as internal (since they’re within the same
confederation).
○​ To the external world, all routers still appear as part of the main AS.

In the following example, let’s assume your organization is AS 65000. You break it into:
●​ Sub-AS 65001
●​ Sub-AS 65002
●​ Sub-AS 65003

These sub-ASes form a confederation and share a common external AS number, 65000. To an
external peer, all routers in 65001–65003 still look like they’re in AS 65000. Below are configurations
snippets for this example
! On Router in Sub-AS 65001:
router bgp 65001
bgp confederation identifier 65000
bgp confederation member-as 65002 65003

! On Router in Sub-AS 65002:

router bgp 65002
bgp confederation identifier 65000
bgp confederation member-as 65001 65003

! On Router in Sub-AS 65003:

router bgp 65003
bgp confederation identifier 65000
bgp confederation member-as 65001 65002

Settings for Large BGP Routing Tables.

When the BGP routing table size is more or more full routing tables (750K routes and above), it is
required to add ipstack and bgp message buffers to boost performance. To do so, follow these steps:
1.​ Make sure you are running router version 1.12.55.B3P34 or later.
2.​ Make sure you have at least 6G in the heapsize setting in the DP configuration file. The DP
configuration file is located at /usr/local/certus/etc/hdp/startup_all.conf and the
heap size setting is last line in the configuration file (e.g heapsize 8G).
3.​ Create a file (if not existing already) on the router’s host with the following path​
/usr/local/certus/etc/[Link]
4.​ Modify this file by adding the following two lines of configuration​
bgpd 500​
ipstack 500
​
This will increase the buffer size of BGP and IPstack modules so that they can buffer more packets to
sustain BGP performance pressure when dealing with large routing tables. The default set buffer
 values are 100M for ipstack and 10M for all other modules when these parameters are not explicitly
set.

You need to restart the router by “flexbng -s” for the changes to take effect.

BGP Troubleshooting
Here are some common pitfalls and useful debug commands for BGP related troubleshooting:
●​ Examine the configuration to make sure
○​ the router AS number and neighbor AS numbers are configured correctly.
○​ you can ping the neighbor IP
○​ From the neighbor, make sure you can ping the router IP associated with the update
source interface for that neighbor.
○​ Make sure you have at least one address-family ipv4-unicast/ipv6-unicast
configured for the bgp instance and for each neighbor.
●​ User command “show bgp summary default” to check bgp status. If the state is stuck at
IDLE, it usually indicates there is something wrong with the configuration. If the configuration is
ok for the BGP process to work on, the state will either be ACTIVE (bng is trying to negotiate
with neighbors) or ESTABLISHED. The minimal configurations for the BGP are
○​ BGP AS number and this BGP router-id
○​ Global address family (address-family ipv6-unicast or address-family
ipv4-unicast or both)
○​ Neighbor AS and neighbor IP
○​ Neighbor address family (address-family ipv6-unicast or address-family
ipv4-unicast or both)
●​ If the BGP state is stuck in IDLE, one common cause is that there is capability mismatch, you
can configure override-capability under that neighbor to override capability mismatches.
Keep in mind that this option is under each neighbor configuration.
●​ If you are running BGP with a full routing table or larger, it is recommended to set the BGP
update cache buffer to 500M. To set BPG update cache buffer size, follow these steps:
○​ Create/modify the file “/usr/local/certus/etc/[Link]”. This file does not
exist by default. If you are setting the BGP cache buffer size for the first time, you will
have to create this file.
○​ Create the key value pair “bgpd 500”, where 500 means 500 million.
○​ Restart the router by “flexbng -s” for the change to take effect.
●​ When the router sends BGP exchange packets to its configured neighbor, the source IP of
these packets will be those associated with the interface configured under update-source for
that neighbor. The update-source can be a loopback interface or any interface on the
router. Also the configuration of update-source is optional. Given all these possibilities, you
want to make sure that the source IP of BGP packets matches the neighbor IP configured on
the BGP peer router. If the source IP of the BGP packets received does not match what is
configured for that neighbor on the peer router, the packets will be dropped by the peer router.
●​ For eBGP connections, make sure the key “ebgp-multihop” under each neighbor is set to a
value that reflects the number of hops for the router to reach the peering neighbor. Since direct
connections between ebgp neighbors are expected, by default the TLL value for BGP packets
is set to 1. If there are multiple hops on the eBGP links, you need to set "ebgp-multihop"
accordingly. A good debug trick is to set it to 255 to leave plenty room for TLL.
 ●​ Use “show bgp neighbor” to display neighbor status. This command will also display error
messages related to bgp neighbors if there are any..
●​ Use “show bgp neighbor-route all” to display route advertisements and receive
summary on all neighbors.
●​ If you have routes not being advertised as they should and you have route maps in place to
control route advertisement or receipt, make sure your changes to the route maps rules are
recognized by the router by removing and adding the rules back to trigger bgp to refresh route
map rules as explained earlier.
●​ If static configured routes are not being advertised, please make sure you have
“redistribute static” specified under “address-family ipv4-unicast”
●​ If routes are not being advertised, please check if you have the “update-source <update
interface>” specified for that neighbor.
●​ To display bgp status for a particular neighbor, use the command ​
“show bgp neighbor <neighbor-IP> default”
●​ To display what networks are advertised or received to neighbors, use the command ​
“show bgp neighbor-route all default <neighbor-IP> advertise”​
“show bgp neighbor-route all default <neighbor-IP> receive”​
For example, show bgp neighbor-route all default [Link] receive
displays all received routes from bgp neighbor [Link]
●​ To reset BGP with a neighbor type “clear-bgp neighbor <neighbor ip>”
●​ To reset BGP route exchange with all neighbors without bringing the neighbor state up/down,
use the command “clear-bgp all in/out”. This command resets the router exchange in
either the in or out direction. To reset routes to a particular neighbor, use the command “
clear-bgp neighbor <neighbor IP> in/out”. To reset routes in both directions, you
have to run the command twice with both the in and out as direction values.
●​ Examine BGP log if necessary. The BGP log is located at /var/log/certus/bgpd

ISIS

ISIS Configuration
A typical ISIS router configuration example is shown below.

router isis
instance CORE
isis-level ​ level-2
dynamic-hostname normal
isis-level-2-cfg metric-type wide
nsap-address 49.0000.1852.2816.0010.00
redistribute connected
address-family-ipv6-cfg redistribute connected
interface eth-trunk1.8
enabled
ipv6-enabled
level ​ level-2
interface-type point-to-point
level-2 metric 25
exit
interface loopback0
passive
 level ​ level-2
interface-type point-to-point
exit
exit
exit

NOTES:
●​ If the peer is using wide metric, you need to configure “isis-level-2-cfg metric-type
wide” as shown in the example in red

ISIS troubleshooting
●​ “show isis-state neighbors all”​
display isis state neighbors
●​ “show isis-state database level-2 detail”​
display isis route database
●​ “show route ipv4 isis”​
display IPv4 isis route
●​ “show route ipv6 isis”​
display IPv4 isis route

Use tracker to detect link state change and update routing table
You can enable ping detect or BFD to detect interface connectivity changes and trigger updates to the
routing table accordingly. This applies only to static routes and BGP. This feature is illustrated in the
following examples.

Update Static routes with ping detect tracker

detect-group route1-detect
option and
test-type icmp-echo
retry-count 2
loop-time 15
timeout 2
sampling-period 30
detect-list 1 [Link] interface 10gei-1/1/0
exit
detect-group route2-detect
option and
test-type icmp-echo
retry-count 2
loop-time 15
timeout 2
sampling-period 30
 detect-list 2 [Link] interface 10gei-1/1/1
exit

tracker
track route1-track ping-detect group route1-detect
track route2-track ping-detect group route2-detect
exit

router static
ip route [Link] [Link] ifname-nexthop 10gei-1/1/0 [Link] track
route2-track
ip route [Link] [Link] ifname-nexthop 10gei-1/1/1 [Link] track
route1-track
exit

In the above example, we have two static routes. When both routes are available, the traffic using
static routes will be evenly distributed between these two routes. If one is down and fails ping detect
tracker, the router will mark the corresponding static route unusable and avoid sending traffic to it
while it is down. Similarly, traffic will resume when the ping detect tracker detects the interface is
available again.

Update BGP routes with ping detect tracker

detect-group my-ping-detector
option and
test-type icmp-echo
retry-count 2
loop-time 15
timeout 2
sampling-period 30
detect-list 1 [Link] interface 10gei-1/1/3.471
exit

tracker
track-group my-ping-tracker
track test
exit
track test ping-detect group my-ping-detector
exit

router bgp 11
neighbor [Link]
remote-as 1111
track my-ping-tracker
synchronization
 exit
address-family ipv4-unicast
soft-reconfiguration-inbound
exit
exit
exit

In the above example, we defined a ping tracker to track the presence of a BGP neighbor by ping.
The tracker is then bound to that neighbor. If the tracker declares this neighbor is down/up, the BGP
router will act accordingly in terms of route advertising and receiving operations with the neighbor.
You may wonder why this is needed since neighbor state detection is already built into the BGP
protocol. The reason is that ping detect can detect the presence of a neighbor faster than the state
machine built into BGP.

Update BGP routes with BFD tracker

To update BGP routes based on BFD tracker state, follow these steps
1.​ Create a BFD session. In the BFD session, configure the following
a.​ The neighbor IP, which is the BGP peer IP.
b.​ The local IP, which is the IP address on the BNG’s BGP update interface.
c.​ BFD update intervals, which consists of the following:
i.​ min_tx -> the BFD packet sending interval from the BNG.
ii.​ min_rx -> the expected interval to receive BFD packets from the peer.
iii.​ multiplier -> the BFD robustness factor. If the BNG router does not receive
the number of consecutive BFD packets specified by the multiplier from its peer,
it will declare the BFD session down.
d.​ Use the command “show bfd” to check the BFD status after BFD is configured.
2.​ Create a tracker on the BNG to monitor the BFD status. You can use the command “show
tracker” to check the tracker status after configuration. Make sure the BFD session or
tracker-group status is up before binding BFD to BGP; otherwise, it will cause the BGP session to
go down.
3.​ Bind the tracker-group to BGP so that BGP can follow the BFD status
​
Here is an configuration example
! create a bfd session to the router’s neighbor peer
bfd
session 1
bind neighbor [Link] local [Link]
interval min_tx 50 min_rx 50 multiplier 3
exit
exit

! create a tracker to track the bfd state

tracker
track-group bfd-for-bgp
track bfd-session
 exit
track bfd-session bfd session 1
exit

! attach the tracker to the relevant bgp neighbour

router bgp 12345
neighbor [Link]
remote-as 12345
track-bfd bfd-for-bgp
exit
address-family ipv4-unicast
exit
exit
exit

Policy Based Routing (PBR).

Often you run into a situation where you have multiple upstream providers connected to multiple different
interfaces and you want to set up policy so that you can route subscriber’s traffic to different providers
based on subsribers’s IP addresses. To achieve this on the netElastic vBNG, you need to setup the
following configurations:
●​ First make sure there are routes for each of the egress interfaces. For example, if you are using
static routes and you have three egress interfaces, you need to first create three static routes on
the router with three next hop IP addresses.
●​ Classify the subscriber traffics based on their source IPs. This should be done by the
combination of access list and class map.
●​ Define routing behaviors.
●​ Define policies that bind the traffic classifications (class_map) together with the intended routing
behavior.
●​ Define user qos profiles based on the policies defined. This is optional, but required if you need
to apply the policy to users as user qos policies (bound to user’s authorization template)
●​ Apply the policy to the user ingress interface or bind the user qos profile to the user’s
authorization template. Since PBR is source IP based, you only need to bind a PBR policy in the
“in” direction on the ingress interfaces.

Here is an example with the following specifications:

●​ The vBNG is connected to two ustream carriers
○​ CarrierA: next hop [Link] on interface 10gei-1/1/1.200
○​ CarrierB: next hop [Link] on interface 10gei-1/1/1.300
●​ Traffic with source IP [Link]/20 and [Link]/24 goes to CarrierA
●​ Traffic with source IP [Link]/20 and [Link]/24 goes to CarrierB
●​ Subscribers come in on interface 10gei-1/1/0.500 and 10gei-1/1/0.600

Below are the configurations

! access list for user traffic that is supposed to go to carrierA

access-list user-traffic-for-carrierA
 rule 10 permit ip source [Link]/20 destination any
rule 20 permit ip source [Link]/24 destination any
rule 100 deny ip source any destination any
exit

! access list for user traffic that is supposed to go to carrierB

access-list user-traffic-for-carrierB
rule 10 permit ip source [Link]/20 destination any
rule 20 permit ip source [Link]/24 destination any
rule 100 deny ip source any destination any
exit

! class map for user traffic that is supposed to go to carrierA

class_map user-traffic-for-carrierA match-way match-any
match ipv4-access-list user-traffic-for-carrierA
exit

! class map for user traffic that is supposed to go to carrierB

class_map user-traffic-for-carrierB match-way match-any
match ipv4-access-list user-traffic-for-carrierB
exit

! define routing behavior to carrierA

behavior route2carrierA
item 1
set ip next-hop [Link] ifname 10gei-1/1/1.200
exit
exit

! define routing behavior to carrierB

behavior route2carrierB
item 1
set ip next-hop [Link] ifname 10gei-1/1/1.300
exit
exit
! define outgoing route policy
policy pbr-policy
class_map user-traffic-for-carrierA behavior route2carrierA
class_map user-traffic-for-carrierB behavior route2carrierB
exit

! apply route policy to access user interface

interface 10gei-1/1/0.500
bind qos in pbr-policy
dot1q 500
exit

! apply route policy to access user interface

interface 10gei-1/1/0.600
bind qos in pbr-policy
dot1q 600
exit

Additionally if you want to apply the policy as a user qos profile and apply to the user by its authorization
template, continue to configure the following.

! define user qos profile to user the pbr policy

bras
 user-qos-profile pbr-user-profile
input-qos-policy pbr-policy
exit
exit

! apply the qos profile to the user's access authorization template.

bras
authorization user-authorization
authorization-type mix-radius
user-qos-profile pbr-user-profile
nat-type none
radius-nat-switch disable
exit
exit

VRF Configuration
netElastic’s vRouter supports total routing and access control separation through VRF (Virtual Routing
and Forwarding). Pretty much every component that we have covered so far can be put into a VRF
context to achieve the desired separation of separate router instances. In addition, radius access can
also be put into a separate VRF to isolate the radius control traffic from the forwarding traffic path. Next
we will provide a couple of examples to illustrate some of the practical VRF use cases.

Use VRF to create separate access and routing entities.

A typical use case of using VRF is to create multiple “virtual routers” within one router instance to have
total access and routing separation between two or more routing applications. For example, you may
have a situation where you want a subset of router interfaces to serve one customer base and route their
traffic to carrier A while simultaneously using another subset of router interfaces to serve another
customer base and route their traffic to carrier B. This can be achieved by using a separate VRF to
separate all access and routing related to carrier B from those associated with Carrier A. The
configuration of the router involves the following steps:
1.​ Create a VRF instance for carrier B.
2.​ Bind the VRF instance for the IP pool definition associated with the carrier B
3.​ Bind the VRF instance for the WAN and VGI interfaces associated with the carrier B.
4.​ Bind the VRF instance for the access domain associated with the carrier B access network.
5.​ Bind the VRF instance for the NAT public IP pool associated with the carrier B. This won’t be
applicable if NAT is not being applied. For detailed information about nat configuration under the
context of VRF, please refer to the NAT rules under VRF note.
6.​ Bind the VRF instance for the router instances (static routes/BGP/OSPF/ISIS,etc) associated with
the carrier B

The following is a configuration example of the above mentioned use case.

! create VRF instance VRF-CARRIER-B
l3vpn vrf VRF-CARRIER-B
exit

! bind VRF to the Wan interface of carrier B

interface gei-1/1/2
bind vrf VRF-CARRIER-B
ipv4 address [Link] 31
exit

! bind VRF to the VGI interface of carrier B’s access gateway

interface vgi3
bind vrf VRF-CARRIER-B
ipv4 address [Link] 24
exit

! bind VRF to the carrier B’s subscriber IP pool

ippool group local_ipv4_pool_pppoe_VRF_TEST
gateway-ip [Link] gateway-mask [Link]
bind vrf VRF-CARRIER-B
lease-time ​ 360
dns-primary [Link] secondary [Link]
ippool-status ​ unlock
warning-threshold 80
warning-exhaust disable
frame-ip lease manage disable
section start-ip [Link] end-ip [Link]
exit
exit

! bind VRF to the carrier B’s access domain

domain my_domain_pppoe-VRF-CARRIER-B
bind authentication-template my_radius_authen_temp
bind accounting-template my_radius_acct_temp
bind authorization-template my_author_temp_local
bind vrf ​ VRF-CARRIER-B
vgi ​ vgi3
bind-pool 1 local_ipv4_pool_pppoe_VRF_TEST
exit

! bind VRF to carrier B’s static route config

router static
ip route [Link] [Link] ifname-nexthop gei-1/1/3 [Link]
ip route vrf VRF-CARRIER-B [Link] [Link] ifname-nexthop gei-1/1/2
[Link]
exit
 Use VRF to isolate radius control traffic.
In this example, we will create a VRF called “radius-vrf” and bind radius authentication, accounting,
and dmcoa to the VRF. Other “radius-vrf” related configurations like interfaces and routings are similar to
what was shown in the previous example and are thus omitted in this example.

! create VRF called radius-vrf

l3vpn vrf radius-vrf
exit

! bind radius authentication, accounting, and dmcoa to the VRF radius-vrf

radius authentication bind vrf radius-vrf
radius accounting bind vrf radius-vrf
radius dmcoa bind vrf radius-vrf

Http redirect, walled garden, and portal access

netElastic vRouter supports various ways of http redirect operations. Not only it provides the flexibility in
redirect trigger conditions, it also provides a very flexible configuration method for users to customize the
redirect URL format to carry information such as the user's MAC, IP address, user name, etc.

http redirect applies in the following scenarios.

1.​ Static Redirect: ​
Redirect happens immediately as soon as redirect configurations in the user’s access domain are
committed. To remove redirect, redirect configurations have to be removed, committed, and
users have to reconnect to the router.
2.​ Dynamic Redirect/Walled Garden: ​
Redirect happens when the router receives redirect instruction from radius DMCOA message.
Redirect can also be removed dynamically by radius DMCOA message
3.​ Portal Access Control:​
This relates to portal user access control flow. Users will be redirected to the portal as part of the
authentication process. After user information is entered in the portal, the vBNG router will use
the information to authenticate users against the radius database. For more information on portal
flow, please refer to the netElastic Portal Authentication Configuration Guide

Static HTTP Redirect

Always Redirect Upon Authentication

Subscriber’s http traffic will be redirected upon authentication if the following are configured under the
subscriber’s access domain:
1.​ Configure ACL rules that limit the subscriber’s access to only those destinations you allow it to
access. This normally includes intended http redirect destinations and DNS servers. You can
create the rule based on the subscriber's IP prefix and allowed destination prefix. Make sure to
 use the catch-all “deny all” as the last rule in the access list. You need to create inbound and
outbound ACLs and combine them to create a user ACL profile.
2.​ Bind the user ACL profile defined above to the user’s authorization template using the key
special-acl. This ensures that the ACL is applied to the subscriber for redirecting traffic.
3.​ Configure redirect http base URL and optionally configure redirect http URL parameter fields to
carry subscriber’s information as URL parameters to the captive portal server. To configure a web
redirect url and its parameters, use config -> bras -> web-url [url template id].
You can define up to 10 web url templates. Here are the web url template configuration keys
a.​ firsturl-key - set the key for user’s original URL before being redirected
b.​ key-delimiter ​ - set url parameters delimiter character
c.​ key-host-name ​ - set the key for host name configured under
system->hostname
d.​ key-mscg-name ​ - set the key for mscg parameter defined under mscg-name
e.​ key-nas-ip ​ - set the key for nas ip defined under nas-ipaddr
f.​ key-ssid ​ - set the key for ssid defined under ssid
g.​ key-user-circuit-id - set the key for user's circuit ID in dhcp option 82
h.​ key-user-ip ​ - set the key for user’s ipv4 address
i.​ key-user-ipv6 ​ - set the key for user’s ipv6 address
j.​ key-user-location - set the key for user’s access circuit interface (VCI) (e.g.
10gei-1/1/1.300)
k.​ key-user-mac ​ - set the key for user’s MAC address
l.​ key-user-remote-id - set the key for user's remote ID in dhcp option 82
m.​ mscg-name ​ - set the mscg parameter
n.​ nas-ipaddr ​ - set the nas ip parameter
o.​ ssid ​ - set the ssid parameter
p.​ url ​ - set the http redirect base IPv4 URL
q.​ urlv6 ​ - set the http redirect base IPv6 URL​

The redirect URL will take the form of [base url] ? [key=value] [delimiter]
[key=value] [delimiter] [..more key value pairs]. Here is an example of what the
redirect URL looks like with the following web url template configurations:​
​
[Link]
300,nas=myNas,host=myBNG

bras
web-url 1
url ​ [Link]
key-user-ip ​ ipv4
key-user-mac ​ mac
key-user-location inf
key-delimiter ​ ,
key-mscg-name ​ nas
key-host-name ​ host
mscg-name ​ myNas
exit
exit
 ​
NOTES about the redirect URL
●​ If you need to include a custom field with a fixed parameter, you can configure
key-mscg-name as the key name and mscg-name as the key value.
●​ The total assembled URL (base section + parameter section) must not exceed 255
characters.​

4.​ Bind the above defined web url template to the user’s access domain.

Here is an example of static HTTP redirect configuration:​

! define ACL and associate user ACL profile

access-list blocked-in
rule 10 permit ip source [Link]/32 destination [Link]/21
rule 200 deny ip source any destination any
exit
access-list blocked-out
rule 10 permit ip source [Link]/21 destination [Link]/32
rule 200 deny ip source any destination any
exit
bras
user-acl-profile redirect-acl-profile
input-acl-profile blocked-out
output-acl-profile blocked-in
exit
exit

! bind the user acl profile to user’s authorization template

bras
authorization myAuthorization
authorization-type local ! make sure to NOT set authorization-type to none
special-acl ​ redirect-acl-profile
nat-type ​ none
radius-nat-switch disable
exit
exit

! define web url template

bras
web-url 1
url ​ [Link]
key-user-ip ​ ipv4
key-user-mac ​ mac
key-user-location inf
key-delimiter ​ ,
key-mscg-name ​ nas
key-host-name ​ nas
mscg-name ​ myNas
exit
exit

! bind web url template to the user’s access domain

bras
domain myDomain
bind authentication-template myAuthentication
bind authorization-template myAuthorization
vgi ​ vgi1
 domain-status ​ unlock
user-routing-distribute ​ disable
user-ipv6-routing-distribute disable
tunnel-domain ​ disable
flow-statistic ​ enable
web-url-index ​ 1
radius-attribute qos-acl-profile no-exist-policy offline
radius-attribute qos-profile no-exist-avp offline
quota-out offline
bind-pool 1 ippool1
exit
exit

Keep in mind that for statically configured http redirects, redirection happens immediately after the
web-url-index is added and committed in the user’s associated domain definition. To take users off
from redirection, you have to either manually remove web-url-index from the domain definition or
set NetElastic-Portal-Mode to “0” from radius via radius DMCOA message. See the next
session on dynamic http redirection for more details on how to use DMCOA message to remove user
from redirection.

Conditional Redirect By Radius Authentication Instruction

In this case, the user’s online request is sent to the RADIUS server for authentication. The RADIUS
server responds with an Access-Accept message and includes a RADIUS reply attribute that places the
user into the redirect domain defined earlier.

To achieve this workflow, follow these steps:

1.​ Define a redirect domain and its associated components as described above.
2.​ When the user’s authentication is approved, the RADIUS server should reply with the netElastic
RADIUS attribute NetElastic-Domain-Name (netElastic VSA 138) and assign it the domain
name value defined in Step 1.

Conditional Redirect Upon Authentication Failure

IIn this case, the user’s online request is denied by the RADIUS server. The BNG router can be
configured to place the user into a redirect domain when the authentication request is denied.

To achieve this workflow, follow these steps:

1.​ Define a redirect domain and its associated components as described above.
2.​ In the user’s authentication template add the following configuration​
authen-fail online author-domain [redirect domain]

Dynamic HTTP Redirect/Walled Garden by Radius DMCOA

Subscriber can be put into walled gardens dynamically either by Radius COA or Radius Reply
messages. To achieve this, you need to do the following:
1.​ Configure ACL rules that limit the subscriber’s access to only those destinations you allow it to
access. This normally includes intended http redirect destinations and DNS servers. You can
 create the rule based on the subscriber's IP prefix and allowed destination prefix. Make sure to
use the catch-all “deny all” as the last rule in the access list. You need to create inbound and
outbound ACLs and combine them to create an user access list profile as shown in the following
example. This user ACL profile is what radius will send over to direct the vBNG to put the
subscriber under the ACL rules associated with this ACL profile.​

access-list blocked-in
rule 10 permit ip source [Link]/32 destination [Link]/21
rule 20 permit ip source [Link]/32 destination [Link]/21
rule 200 deny ip source any destination any
exit
access-list blocked-out
rule 10 permit ip source [Link]/21 destination [Link]/32
rule 20 permit ip source [Link]/21 destination [Link]/32
rule 200 deny ip source any destination any
exit
bras
user-acl-profile blocked
input-acl-profile blocked-out
output-acl-profile blocked-in
exit
exit

2.​ Under the subscriber’s radius authentication group set the filter-id-type to special-acl
instead of user-acl. The switch filter-id-type controls where the received acl from radius
under the attribute Filter-Id will be applied to, i.e. user-acl or special-acl. With the
user-acl, once assigned, the acl will take effect until another acl is applied. With the
special-acl, the assignment from radius will be removed when NetElastic-Portal-Mode is set
to 0. This will free the subscriber from the special-acl limitations. Here is an example of the
radius authentication group configuration.​

radius authentication group radius_auth_grp

server-type ipv4-server
timeout 3
retry-times 3
nas-ip-address [Link]
algorithm master
dead-time 5
dead-count 10
class-as-car disable
filter-id-type special-acl
server 1 ipv4-address [Link] port 1812 key dodonet321
exit

NOTE: Once you set the filter-id-type to special-acl in the authentication template, all
subsequent attributes Filter-Id received from radius (including those in COA messages) will
be treated as special-acl. If you want to control subscribers’s normal ACL, you can do so by
using the netElastic VSA attribute “NetElastic-Data-Filter”

3.​ To put user into walled garden, send the following from radius​
 Acct-Session-Id = 15856914162058990000c298d4e4e​
# User-Name = JohnSmith # you can also use user name as handle instead of accounting id
NetElastic-Portal-Mode = 1
NetElastic-HTTP-Redirect-URL = [Link]
Filter-Id = blocked

4.​ To put the user out of the walled garden, send the following from radius. You can use either the
accounting ID or user name to identify the user. ​

Acct-Session-Id = 15856914162058990000c298d4e4e
# User-Name = JohnSmith
NetElastic-Portal-Mode = 0

To check if the user is put into a walled garden or not, you can examine the “webforce-info” section in
the user session details to make sure the relevant fields related to the walled garden are all set as
shown in the following user session detail snippet.
webforce-info ​ "webforce-flag 1 adforce-flag:0 special-acl: restricted
http-url: [Link] advertisement-url:"

NOTE 1 : special ACL will only take effect when vBNG receives all three attributes (Filter-Id,
NetElastic-Portal-Mode, and NetElastic-HTTP-Redirect-URL). If any of them is missing, the
others will not take effect. For example, if the URL is missing, the ACL won’t take effect even if
Filter-Id is set and NetElastic-Portal-Mode is set to 1. You can check if all the attributes are sent
to the user by checking the user’s smgr session detail information. For example “show smgr-session
detail by-user-name JohnSmith”
NOTE 2 : In addition to using “Acct-Session-Id” as the subscriber handle as shown in the above
examples, you can also use “User-Name” to put subscribers in and out walled gardens.
NOTE 3 : To optionally modify the web redirect url parameters to carry user information, you can create
a web url template and bind it to the user’s access domain in exactly the same way as explained in the
static http redirect case explained above.

Prepaid Online Access Http Redirect

Prepaid service is a common service offered by many ISPs. With this service,customers prepay for
either a time-based or usage volume based solution and use the service until the paid quote runs out.
This use case involves the following details.
●​ Users usually bring their own device and connect to the ISP’s network via IPoE access.
●​ Users are immediately put into walled garden where limited internet access is granted to allow
users access signup portal to prepay for usage.
●​ Once users sign up, users are removed from the walled garden by radius COA so normal internet
access can be granted.
●​ Upon the user's quota reaches the limit, radius puts the user back into walled garden to renew
payment.
​
The prepaid quota setting and redirect behavior can be either statically configured on the vBNG router
or dynamically by radius replay/dmcoa messages.
Statically Configure Usage Quota and Redirect Behavior.
To statically configure usage quota and redirect behavior,you need to configure:
●​ User usage quota in the user’s authorization template.
●​ Online behavior when the user's quota reaches a limit. Here you can specify to let users continue
to be online, or kick the user offline, or redirect to a captive portal website with an access list
profile.

Here is a configuration example with relevant configurations highlighted in red.

! set the user's prepaid quota in either volume or time or both, in which case
! whichever expires first takes precedence.
bras
authorization myAuthorization_200m
authorization-type mix-radius
prepay flow 1000000 type dual ! set volume quota in down, up, or both directions
prepay time 36000 ! set time quota
user-qos-profile user_qos_500kbpsUp_500kbpsDown
bind nat-domain-name myNatRule
nat-type ​ inside
radius-nat-switch disable
exit
exit

! set quota out behavior

bras
domain myDomain
bind authentication-template radiusAuthentication_netElastic
bind authorization-template myAuthorization_200m
bind-addr-pool ​ ipoe_ipv6_addr_pool
vgi ​ vgi1
domain-status ​ unlock
user-routing-distribute ​ enable
user-ipv6-routing-distribute disable
tunnel-domain ​ disable
flow-statistic ​ enable
radius-attribute qos-acl-profile no-exist-policy offline
radius-attribute qos-profile no-exist-avp online
quota-out redirect-url online [Link] redirect-acl
port-white_list
! quota-out redirect-url online ! can also set to online/offline/updateQoS
bind-pool 1 localPool
exit
exit

Dynamically Set Usage Quota and Redirect URL

Dynamically setting usage quota and redirect URL involves two steps:
●​ Setting Usage Quota​
This is done via radius reply message with private attribute NetElastic-Remanent-Volume
and NetElastic-Remanent-Volume-Type.
●​ Set the redirect URL, access list, and put the user to the walled garden.​
This step is the same as the walled garden redirect as discussed above.
 Portal Access Control.

For portal access control web redirect related information on portal flow, please refer to the netElastic
Portal Authentication Configuration Guide

IP Flow Information Export (IPFIX)

IPFIX Configuration
netElastic vRouter supports ipfix flow analytics exporting beginning in version 1.12.57.B4P12

Here is a typical ipfix configuration for exporting flow analytics to an external collection server.

ipfix
recorder flow-def
match protocol
match ipv4-src-address
match ipv4-dest-address
match ipv6-src-address
match ipv6-dest-address
match src-port
match dest-port
match intf-dir
collect input-intf
collect output-intf
collect bytes-counter [ total ]
collect packets-counter [ total ]
collect flowstartmilliseconds
collect flowendmilliseconds
collect flowendreason
collect user-name
exit
sampler sampler-def
sample randomized-packets 100
exit
exporter exporter-def
protocol netflow-v10
ipv4-src-address [Link] ipv4-dest-address [Link]
udp-port 4739
exit
! optionally you can add a second exporter to export flows
! to a backup collector
exporter exporter-def-backup
protocol netflow-v10
ipv4-src-address [Link] ipv4-dest-address [Link]
udp-port 8023
 exit
monitor monitor1
sampler sampler-def recorder flow-def
exporter exporter-def
exporter exporter-def-backup
timeout active 60
timeout inactive 15
interface 10gei-1/1/0
interface 10gei-1/1/3.301
interface 10gei-1/1/3.3033
exit
exit

The ipfix configuration has the following modules:

●​ flow metrics and flow attribute template definition. This is defined under the recorder template
definition which has the “match” and “collect" sections. The “match” section defines the flow
elements that form the flow analytics. The “collect” section defines what additional metrics
(e.g. in/out interfaces, byte counts, etc) to be collected for the flow defined under the “match”
section.
○​ The following flow elements can be matched for flow analytics.
■​ dest-port ​ Match destination port
■​ intf-dir ​ Match direction of flow
■​ ipv4-dest-address Match destination address
■​ ipv4-src-address​ Match source address
■​ protocol ​ Match Protocol
■​ src-port ​ Match source port
■​ tos ​ Match type of service
○​ The following metrics can be collected for the flows defined
■​ bytes-counter ​ counter of bytes of the flow records. By
default the bytes counter will count bytes in the ingress and
egress directions separately and export as Octets and Post
Octets respectively. You can optionally configure the “total”
option (e.g. collect bytes-counter total) to combine the
Octets and Post Octets together and export the value as
Octets
■​ input-intf ​ input interface of the flow records
■​ output-intf ​ output interface of the flow records
■​ packets-counter counter of packets the flow records. By
default the bytes counter will count packets in the ingress
and egress directions separately and export as Packets and
Post Packets respectively. You can optionally configure the
“total” option (e.g. collect packets-counter total) to
combine the Packets and Post Packets together and export the
value as Packets.
■​ flowstartmilliseconds flow start time in milliseconds
■​ flowendmilliseconds flow end time in milliseconds
■​ flowendreason termination reason for the reported flow
■​ user-name user-name of the flow records
●​ flow sampler definition. The sampler template defines how the flow sampling should be carried
out. The sample key has the following options.
○​ fixed-packets ​ N (integer 10..65535)​
sample once every N packets, and use the packet at the sampling location for flow
analysis.
○​ fixed-time T (integer, 10..65535)​
sample once every T seconds, and use the packet at sampling time for flow analysis
○​ randomized-packets ​ N (integer, 10..65535)​
sample once every N packets, but use one random packet within the N packets for flow
analysis
○​ randomized-time ​ T (integer, 10..65535)​
sample once every T seconds, but use one random packet within the sampling period
for flow analysis
●​ exporter definition. Flow analytics will be exported to an external collector by UDP transport. The
exporter template defines how the flow analytics is going to be sent out to external flow analysis
collectors. Within the exporter template, you can define
○​ protocol [netflow-v9 / netflow-v10]​
defines the flow exporting protocol.
○​ ipv4-src-address src-IP ipv4-dest-address dst-IP​
defines the flow exporting UDP packet source IP and destination (collector) IP
○​ udp-port​
defines udp port of the udp transporting packets for exporting flow analytics.
●​ monitor definition. The monitor section binds the flow metrics, sampler, exporter definitions, and
applicable interfaces together and creates a low analysis and exporting instance.
○​ exporter [recorder template]​
bind the exporter template
○​ sampler [sampler template] recorder [flow template]​
bind the sampler and record template
○​ interface [interface]​
list of interfaces on which flows will be analyzed. Currently, our IPFIX implementation
supports flow export on the following interface types and directions:​

■​ physical interfaces​
support flow information exporting in both ingress and egress directions
■​ eth-trunk interfaces​
support flow information exporting in egress direction only
■​ sub interfaces of physical or eth-turnk interfaces ​
support flow information exporting in egress direction only
■​ inside logic interfaces (e.g. vgi, loopback etc)​
does NOT support flow information exporting on these type of interfaces
 NOTE: If the traffic is carried on the VLAN interface on the LAN side and you want to
monitor traffic flows in both directions, you need to add both the physical interfaces and
the VLAN sub-interfaces to the flow monitor.
○​ timeout active [flow active timer]​
set flow active timer in seconds. A flow has to be present for at least the active timer
period for it to be added to the flow analyzer. Within the active timer period, the flow’s
absence can not exceed the inactive timer period.
○​ timeout inactive [flow inactive timer]​
set flow inactive timer in seconds. If there is no new flow for an existing flow within the
inactive timer period, the flow will be deleted.

As soon as the monitor definition is created, the flow analytics and exporting engine begin to be triggered
and flow analytics should begin to be sent to the external collector.

IPFIX Troubleshooting

Check the IPFIX flow tables in the DP

You can check the IPFIX flow tables by following the procedure below.
Note: Please exercise extreme caution — running debug commands in the DP may cause abnormal
behavior if not executed properly. Proceed only if you are certain of what you’re doing.

1.​ Login to the DP shell by typing “telnet 0 5002” in Linux

2.​ Type “show ipfix hash-tbl max-flow-count 10000” to see all flows
3.​ Type “show ipfix hash-tbl max-flow-count 10000 direction in” to see flows in
the in direction
4.​ Type “show ipfix hash-tbl max-flow-count 10000 direction out” to see flows in
the out direction
5.​ Quit back to Linux “q” to quit back to Linux

Common IPFIX Troubleshooting Tips

1.​ If You see IPFIx flows by checking the IPFIX flow tables by the procedure shown above, but no
flows are exported. Make sure
a.​ You have an exporter defined.
b.​ You have bound the defined exporter under the IPFIX monitor definition
2.​ If it appears that flow data is being dropped when using NetFlow v10, ensure that the flow data
packets are arriving at the flow collector in the correct order. NetFlow v10 performs flow order
checking, unlike NetFlow v9, where flow data is sent as individual, independent records.​
Out-of-order flow data can occur when exporting from an eth-trunk interface configured with the
trunk balance mode set to packet-all instead of ip-full. To prevent this, set the eth-trunk balance
mode to ip-full, so that flow data packets destined for the same collector are transmitted through
the same member interface. This happens because they share the same IP hashing index in the
eth-trunk’s load-balancing calculation. Doing so ensures that the order of flow data is maintained
when they are sent from the router.
Lawful Intercept (LI) Configuration
netElastic vRouter supports lawful intercept (LI) that allows legally sanctioned official access to private
subscriber communication contents. When configured and enabled, the entire traffic of all users who are
under lawful intercept cntrol will be mirrored to lawful intercept collecting servers.
The router has two interfaces with the LI servers. They are called x2 and x3 interfaces.
●​ x2 interface: the interface by which the router sends user radius information to the LI servers.
The x2 packet format is [ L2 header | L3 header | UDP /TCP header | User packet ]
●​ x3 interface: the interface by which the router sends user traffic to the LI servers. The x3 packet
format is [ L2 header | L3 header | UDP header | ID | User packet ]

To configure lawful intercept, it involves the following steps:

●​ Configure LI collecting servers.
●​ Configure users whose traffic will be intercepted. The user configuration can be either statically
configured via command line or by API calls through vRouter manager GUI.
●​ Check LI running status to ensure LI is in effect as expected.

LI Server Configuration.
Here is an example of LI Server configuration.

lawful-intercept
ipv4-server li-svr-v4
src-ip ​ [Link]
src-port​ 2332
x3-dst-ip [Link]
x3-dst-port 50010
x3-format udp
x2-dst-ip [Link]
x2-dst-port 50000
x2-format udp
exit
ipv6-server li-svr-v6
src-ip ​ 2001:2345::1
src-port​ 2343
x3-dst-ip 2001:2345::5
x3-dst-port 50010
x3-format udp
x2-dst-ip 2001:2345::5
x2-dst-port 50000
x2-format udp
exit
exit

NOTES:
●​ You can independently configure an ipv4 server and an ipv6 server as shown in the example.
 ●​ src-ip for both ipv4 server and ipv6 server configurations has to be a valid IP already
configured on the router interfaces.
●​ x2-format can have raw, udp, and tcp options, while x3-format only supports udp.

LI Users Configuration.
Here is an example of LI user configuration. Create one instance for each user under LI and you can
have many users as needed. The traffic of all configured user instances will be sent to the LI servers
configured by the x2 and x3 interfaces. Note that the intercept-id field configured in the user
instance will be sent with the user traffic by the x3 interface as shown above in the x3 interface packet
structure.

lawful-intercept
instance johnSmith
intercept-id 1000
ipv6-server li-svr-v6
user-name​ e4-b9-7a-88-f1-d5
user-mac ​ e4:b9:7a:88:f1:d5
user-ipv4​ [Link]
exit
exit

Check LI Running Status.

Use the following commands to check LI running status.
●​ show lawful-intercept-state ipv4-server all​
check ipv4 LI server configuration
●​ show lawful-intercept-state ipv6-server all​
check ipv6 LI server configuration
●​ show lawful-intercept-state instance all​
list all LI user instances configured