Virtual LANs (VLANs) provide greater flexibility in the configuration and use of contexts and services.
They are configured as "tags" on a per-port basis and allow more complex configurations to be implemented. The VLAN tag allows a single physical port to be bound to multiple logical interfaces that can be configured in different contexts. Therefore, each Ethernet port can be viewed as containing many logical ports when VLAN tags are employed.
VLANs can be created at the hypervisor and StarOS levels. Where you create the VLAN depends on your specific network requirements.
VLANs are supported in conjunction with subscriber traffic ports on Management I/O (MIO/UMIO/MIO2) cards. The system supports the configuration limits for VLANs as described in Engineering Rules.
Overlapping IP Address Pool Support – GGSN
Overlapping IP Address pools allow operators to more flexibly support multiple corporate VPN customers with the same private IP address space without expensive investments in physically separate routers or virtual routers.
Resource pools are designed for dynamic assignment only, and use a VPN tunnel (such as a GRE tunnel) to forward and receive the private IP addresses to and from the VPN.
Overlap pools can be used for both dynamic and static addressing, and use VLANs and a next hop forwarding address to connect to the VPN customer.
To forward downstream traffic to the correct PDP context, the GGSN uses either the GRE tunnel ID or the VLAN ID to match the packet. When forwarding traffic upstream, the GGSN uses the tunnel and forwarding information in the IP pool configuration; overlapping pools must be configured in the APN in such instances.
When a PDP context is created, the IP address is assigned from the IP pool. In this case the forwarding rules are also configured into the GGSN. If the address is assigned statically, when the GGSN confirms the IP address from the pool configured in the APN, the forwarding rules are also applied.
The GGSN can scale to as many actual overlapping pools as there are VLAN interfaces per context, and there can be multiple contexts per GGSN. The limit is the number of IP pools. This scalability allows operators who wish to provide VPN services to customers using the customer's private IP address space, not to be concerned about escalating hardware costs or complex configurations.
RADIUS VLAN Support – Enhanced Charging Services
VPN customers often use private address space which can easily overlap with other customers. The subscriber addresses are supported with overlapping pools which can be configured in the same virtual routing context.
Overlapping RADIUS NAS-IP addresses for various RADIUS server groups representing different APNs.
Overlapping RADIUS server IP addresses for various RADIUS servers groups.
Every overlapping NAS-IP address is given a unique next-hop address which is then bound to an interface that is bound to a unique VLAN, thereby allowing the configuration to exist within the same context.
The system forwards RADIUS access requests and accounting messages to the next hop defined for that NAS-IP; the connected routers forward the messages to the RADIUS server. The next hop address determines the interface and VLAN to use. Traffic from the server is identified as belonging to a certain NAS-IP by the port/VLAN combination.
The number of RADIUS NAS-IP addresses that can be configured is limited by the number of loopback addresses that can be configured.
APN Support – PDN Gateway (P-GW)
P-GW Access Point Name (APN) supports extensive parameter configuration flexibility for the APN. VLAN tagging may be selected by the APN, but are configured in the P-GW independently from the APN.