Setting RADIUS Attributes for VPN Connection Bandwidth Limiting

All rights are reserved by NetUP (c) 2001-2007 (www.utm-billing.com).
Republishing is not allowed without explicit permission of NetUP (info@utm-billing.com).
All trademarks used are properties of their respective owners.

Very often in RADIUS Access-Accept packets it is required to transmit attributes that are not provided in the basic billing system configuration, or those having values that should be varied depending on the service type. One of such attributes is that with the vendor code "9" (Cisco) and the value "1" (Cisco-AVPair). This attribute can consist of various string expressions that affect connection parameters. In particular, the attribute may contain:

  1. Values that define which pool of IP addresses should be used for ascribing an IP address to a subscriber. Expression format: ip:addr-pool=POOLNAME
  2. Values that define a bandwidth limit for the current connection. Expression format: lcp:interface-config#1=rate-limit input 64000 8000 8000 conform-action transmit exceed-action drop, where 64000 is a bandwidth in Kb per second. The keyword "input" denotes that the limitation is applied for incoming packets. Replace "input" with "output" if it is required to limit the bandwidth for outgoing packets.

Let us examine creation of a service ?IP traffic transmission? with the bandwidth limited to 64 Kb per second. For that create the service in the billing system ?NetUP UTM? Administrator Control Center. In the section ?RADIUS parameters configuration? create two records:

The first record for limitation of the bandwidth for incoming packets:

Vendor: 9
Attr: 1
Value: lcp:interface-config#1=rate-limit input 64000 8000 8000
conform-action transmit exceed-action drop
Value type: String

The first record for limitation of the bandwidth for outgoing packets:

Vendor: 9
Attr: 1
Value: lcp:interface-config#1=rate-limit output 64000 8000 8000
conform-action transmit exceed-action drop
Value type: String

Figure 1. Setting RADIUS attributes in the billing system NetUP UTM

As a result, on subscriber successful authorization NetUP RADIUS server additionally transmits who attributes mentioned above.

For testing on the NetUP test stand it was used access server Cisco 3640 Version 12.3(11)T3. Role of subscribers was played by two servers managed by Linux Gentoo OS. As a PPTP client it was used pptpclient project [1]. On the access server it was configured pptp server, and an address and a secret key of the RADIUS server were set. Below is an extract from the access server configuration file:

!
no ip cef
vpdn enable
!
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
!
interface Virtual-Template1
ip address negotiated
no peer default ip address
ppp authentication ms-chap-v2 chap
!
radius-server host 10.1.2.6 auth-port 1812 acct-port 1813
radius-server key secret
radius-server vsa send accounting
!

Setting up the PPTP client lies in creation of configuration file /etc/ppp/options of the following content:

name net11debuglocalnoproxyarp

where net11 ~V login of a subscriber registered in the billing system. Password is set in the file /etc/ppp/chap-secrets:

net11   *   123

At that configuration of the PPTP client is complete, and it is possible to establish a connection. For that run the command:

pptp 10.1.2.99

where 10.1.2.99 is a local IP address of the access server.

As a result, after successful authorization between subscriber's PC and the access server it is established a virtual tunnel for packets of the subscriber to pass to external networks. In order to check the connection it is possible to use the command ifconfig on a subscriber's PC. The output should contain information about the ppp0 interface:

ppp0      Link encap:Point-to-Point Protocol
inet addr:172.16.111.146 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:44 (44.0 b) TX bytes:65 (65.0 b)

On the access server the information concerning the tunnel may be obtained by using the command:

show users

Output should contain information about virtual interfaces:

  Interface    User               Mode         Idle     Peer Address
Vi408 net11 PPPoVPDN 00:02:03 172.16.111.146

Bandwidth of the tunnel should be set to 64 Kb/sec. The parameter can be controlled on the access server by using the following command:

show interfaces rate-limit

Output of the command should contain the bandwidth values set on the virtual interfaces:

Virtual-Access408
Input
matches: all traffic
params: 64000 bps, 8000 limit, 8000 extended limit
conformed 0 packets, 0 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 107912740ms ago, current burst: 0 bytes
last cleared 00:03:13 ago, conformed 0 bps, exceeded 0 bps
Output
matches: all traffic
params: 64000 bps, 8000 limit, 8000 extended limit
conformed 0 packets, 0 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 107912744ms ago, current burst: 0 bytes
last cleared 00:03:13 ago, conformed 0 bps, exceeded 0 bps

The speed may be checked by using both standard file copying and special tools [2, 3].

It should be noted that maximal interface number on the access server is limited by number of IDB structures [4]. Information about them can be obtained by the command:

show idb

Output should contain total number of possible structures and number of occupied at the moment:

Maximum number of Software IDBs 800.  In use 732.