DHCP Authorization Setup

L2 DHCP Mode Overview:

BRAS L2 for VLAN/QinQ-networks provides the following features:

  • DHCP: monitoring of the DHCP requests from clients; if the DHCP server reply is successfull, clients will be immediately authenticated via the Radius-protocol
  • ARP proxyLAN ARP requests monitoring, blocking ARP requests from the WAN
  • IP source guard – verification that the LAN packet belongs to the same VLAN from which the DHCP registration was. If this condition is violated, the packet is dropped.
  • Local traffic interconnection (Intra-network traffic exchange between subscribers)
  • Traffic termination from LAN to WAN, origination (grounding) of the responding traffic from WAN to LAN

To perform these functions, fastDPI BRAS needs to know when a client session starts and when it ends, and also operate not only with the IP addresses of users, but also with their MAC addresses and tags of VLAN/QinQ networks. With the help of this knowledge, it is possible to filter out inappropriate requests, thereby increasing security of the local network as a whole.

FastDPI BRAS L2 is suitable for both VLANs and QinQ (double VLAN, VLAN-per-user) networks. The QinQ network is more preferable, since it allows you to uniquely identify the user in a way independent of the user's hardware, but also for a regular VLAN network (with one VLAN packet header), where the VLAN number actually identifies not a user, but a group of users, for example, a house entrance or an entire apartment building, fastDPI BRAS allows you to implement some protection.

BRAS L2 functions are relevant only when fastDPI is used in bridge mode.

BRAS operates primarily on the L2 level, which means that if a packet from LAN is dropped or a decision to send it back to the LAN is taken, the packet payload wouldn't be recognized.

When implementing L2 BRAS (especially using the test bed with few test subscribers) it should be taken into account that due to architectural features and optimization for a large volume of processed traffic, BRAS may handle the subscriber base consisting of 1-2 subscribers incorrectly, that causes the appreciable delays in responses to DHCP/PPPoE packets. For a full-fledged work of L2 BRAS, it is required to load the Stingray Service Gateway with some kind of traffic in order to prevent the idle functioning of worker threads.