Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
en:dpi:dpi_options:brass:l2-connected_bras:opisanie_l2 [2020/02/05 17:38] – ↷ Page moved from en:dpi:dpi_options:base_functionality:brass:l2-connected_bras:opisanie_l2 to en:dpi:dpi_options:brass:l2-connected_bras:opisanie_l2 lexx26 | en:dpi:dpi_options:brass:l2-connected_bras:opisanie_l2 [2020/03/18 14:54] (current) – removed lexx26 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== 1 L2-connected BRAS description ====== | ||
- | {{indexmenu_n> | ||
- | |||
- | ==== Solution Components ==== | ||
- | |||
- | L2-connected BRAS consists of the two components: | ||
- | |||
- | [[en: | ||
- | |||
- | [[en: | ||
- | |||
- | General descripription | ||
- | |||
- | L2-Connected BRAS is designed to work in L2 IP networks when Subscribers are connected to the VAS Experts DPI through intermediate L2 switches. Subscriber traffic can be native IPoE using VLAN, QinQ and/or it can be encapsulated in PPoE. The preferred option of the ones listed above is to use IPoE with QinQ due to its flexibility, | ||
- | |||
- | {{ dpi: | ||
- | |||
- | < | ||
- | The source subscriber MAC addresses within the L2-Connected version are accessible to the BRAS, in addition it acts as an L3 device and terminates the Subscribers IP traffic. Assigning IP addresses to Subscribers is implemented both using DHCP or when the Subscriber sets static IP parameters on his own.</ | ||
- | |||
- | <note warning> | ||
- | |||
- | ==== L2-Connected BRAS specific features ==== | ||
- | |||
- | L2-connected BRAS provides the following functions for VLAN/QinQ networks: | ||
- | |||
- | * Termination of traffic from Subscribers to WAN, termination of response traffic from WAN to Subscribers | ||
- | * DHCP: monitoring of DHCP requests from Subscribers and maintenance | ||
- | * IP source guard – testing whether the LAN packet belongs to the same VLAN the DHCP registration was initiated from. | ||
- | * The local traffic interconnect between subscribers and from subscribers to local resources. | ||
- | |||
- | ==== Differences and advantages in contrast to traditional solutions ==== | ||
- | |||
- | < | ||
- | |||
- | |||
- | * Traffic monitoring and prioritization according to applications and autonomous systems withing the accessible bandwidth of each uplink | ||
- | * Limiting the bandwidth occupied by torrent client traffic in case of common bandwidth shortage (when approaching to maximum bandwidth consumption) | ||
- | * Traffic prioritization according to the applications and autonomous systems within the subscriber’s tariff plan (it is relevant for corporate clients, when many corporate users are working under one tariff plan and the need to allocate a bandwidth so that they do not interfere with one another arises) | ||
- | * Support for Subscribers with an arbitrary IP addresses set, including assigned dynamically ones. | ||
- | * Redirection of Subscribers to the Captive Portal in case of unpaid bills, with an allowed white list of resources, for example, bank portals for payment, based on a domain name or URL, including options with wildcard asterisks | ||
- | * Capability to capture full NetFlow from the entire band or only for billable subscribers | ||
- | * Support for the requirements of regulatory and law enforcement agencies, automatic loading and filtering by the corresponding black lists issued by regulatory authorities | ||
- | * Interaction with lawful interception systems (operates as a trafic extractor for further analysis using statistical means) | ||
- | </ | ||