DHCP relay agent
Description
This mode is intended for the networks where DHCP servers are used to assign IP addresses. This mode is used to track the beginning/end of user session. It is assumed that DHCP servers are placed within a separate network segment that is not directly accessible to users. FastDPI BRAS serves as a relay agent for DHCP requests from user equipment to DHCP servers and for reverse-direction flow, i.e. for responses from DHCP servers to user equipment.
enable_auth=1
is enabled then the Radius Access-Request request for subscriber authorization status along with the user properties (policing and list of activated services) will be generated after the IP address being assigned. If you want to periodically monitor the status of L3-authorization (for example, to observe the length of the session specified by the Session-Timeout
option in the Radius response), then you need to create files aslocal.bin and asnum.dscp specifying which subscribers are local and which ones require periodic L3-authorization.
Configuration
Mode activation:
bras_dhcp_mode=1
Interaction with DHCP-servers is performed through a normal (non-DNA) network interface.
The DHCP server addresses are specified in the fastdpi.conf by the bras_dhcp_server
option, each DHCP server is described by a separate option. The format to be used:
bras_dhcp_server=host%dev:port{;name=val}*
here:
host
– DHCP server IP addressdev
– name of the network interface used to establish connection with DHCP serverport
– port, its default value: 68.name=val
– the advanced options:reply_port
– port to be listened to for the DHCP server responses. The default value is 68.arp_proxy
– the flag specifying the way of handling ARP requests for the DHCP server IP address. If it equals to 1 then the fastDPI will respond to the ARP request for the DHCP server IP address, however the fastDPI MAC address specified by thebras_arp_mac
option will be returned instead of the actual MAC address.alias_ip
- DHCP server alias
alias_ip
is replaced by the actual sever IP address; when receiving a response from the server, SSG performs the reverse substitution.
The example to specify two DHCP servers in the fastdpi.conf:
bras_dhcp_server=192.168.1.1%eth0;arp_proxy=1 bras_dhcp_server=192.168.1.2%eth0;arp_proxy=1;alias_ip=10.0.1.2
If session has been successfully started and L3-authorization mode is enabled (enable_auth=1) then fastDPI BRAS immediately sends the Radius request for the subscriber authorization in order to get up-to-date list of activated services and subscriber policing profile.
Advanced Settings
The list of fastdpi.conf advanced settings related to the DHCP relay agent:
bras_dhcp_opt82
– whether to add the option 82 to the subscriber DHCP request or not. The following values are allowed:- 0 – do not add ever (this is the default value)
- 1 – add if the request is broadcast and if the DHCP request does not yet have opt82 enabled
- 2 - add to any broadcast or unicast request in case the DHCP request does not already have opt82.
bras_dhcp_timeout
– timeout when waiting for a response from the DHCP server, in seconds. The default value is 7 seconds. Note that fastDPI BRAS does not attempt to resend DHCP requests when this timeout expires, it is the subscriber's equipment task. This option only controls the internal structures flushing in case the response from the DHCP server is not received prior to the timeout expiry.bras_dhcp_trusted
– defines how to handle the incoming packets. RFC-3046 assumes that relay agent has an algorithm that allows to determine whether the given DHCP request is generated by trusted or untrusted equipment. Untrusted equipment is the subject to strict requirements,for example, incoming DHCP reguest from untrusted equipment cannot contain option 82, that is, there can not be other relay agents between untrusted equipment and fastDPI. Since the fastDPI is a bridge to which all the requests come and the notion of “port” is absent, it is impossible to implement such recognition algorithm, so this setting is global:- 0 - to consider all the incoming DHCP requests as untrusted; so if the packet contains Opt82, but the the value of
giaddr
field equals to 0 then the packet is dropped [RFC 3046] - 1 – to consider all the incoming DHCP requests as trusted
opt82 option being added by the fastDPI has following values of subfields:
- [1] Agent Circuit ID:
- for VLAN networks: contains the VLAN number represented by 16-digit number in network byte order
- for QinQ networks: contains the outer VLAN number represented by 16-digit number in network byte order
- if VLAN headers aren't used then the sub-option will not be added
- [2] Agent Remote ID: this sub-option is added only when QinQ networks are used and contains the number of the inner VLAN represented by 16-digit number in network byte order
- [12] Relay Agent Identifier Sub-option (RFC6925) - the relay agent identifier.
The subopt12 'Relay Agent Identifier' value is specified by the bras_dhcp_agent_id
option defined in the configuration file and specifies the name of ralay agent which added the opt82 option. It can be used by the DHCP server to define which agent has added the opt82 option. If the bras_dhcp_agent_id
option is not specified in the configuration file then the option will not be added.
Special aspects DHCP Relay agent mode implementation
The Stingray Service Gateway captures all DHCP requests and tries to send it to the corresponding DHCP server defined in bras_dhcp_server option. Broadcast requests are forwarded to the all known DHCP servers. If captured unicast request is forwarded to unknown DHCP server the SSG logs this error event and drops this DHCP request.
Such algorithm is not always acceptable when implementing the DHCP Relay agent mode, - it is often necessary to split the whole implementation process into phases. To do so the SSG starting from version 7.4 uses the bras_dhcp_pass_unknown
configuration option with following valid values:
- 0 - (the default value) - captures all DHCP traffic;
- 1 - to transparently ignore the DHCP traffic being forwarded to unknown DHCP servers.
If bras_dhcp_pass_unknown=1 then unicast DHCP traffic to unkonwn DHCP server will be passed transparrently through the SSG. If Relay agents are located before the SSG in your network then you can specify different DHCP addresses for corresponding Relay agents and therefore to implement the SSG DHCP Relay actually by subnetworks: requests intended for some DHCP servers and known to the SSG will be managed by the SSG itself, the other ones which are unknown to the SSG will be forwarded outside and will be further routed by third-party network equipment to the destination DHCP server.