Cisco Cisco Packet Data Interworking Function (PDIF)
VLANs
▀ Overview
▄ ASR 5500 System Administration Guide, StarOS Release 17
264
Overview
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.
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.
Important:
VLANs are supported in conjunction with subscriber traffic ports on Management I/O (MIO/UMIO)
cards. The system supports the configuration limits for VLANs as described in Engineering Rules.
Overlapping IP Address Pool Support – GGSN
Overlapping IP Address pools provides 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.
with the same private IP address space without expensive investments in physically separate routers or virtual routers.
The system supports two types of overlapping pools – resource and overlap. 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. Overlapping type 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
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. Overlapping type 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.
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.
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.
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.
are supported with overlapping pools which can be configured in the same virtual routing context.
RADIUS Server and NAS IP addresses do not need to be in separate contexts, thereby simplifying APN and RADIUS
configuration and network design. This feature allows the following scenarios to be defined in the same context:
configuration and network design. This feature allows the following scenarios to be defined in the same 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.
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.
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.