Cisco Cisco Packet Data Gateway (PDG)

 

▄  ASR 5500 System Administration Guide, StarOS Release 17 

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 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 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. 

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 

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. 

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. 

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: 



 

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.