Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Wi-Fi Access Gateways

Wi-Fi Access Gateway Overview

The Wi-Fi access gateway (WAG) enables Wi-Fi access for subscribers using residential or business Wi-Fi networks. In a residential deployment, a part of the subscriber’s Wi-Fi network is made available for public use while the private network remains isolated. A public user who have an account with the same service provider can connect to the public Wi-Fi network when they are within range. WAG authenticates and connects subscribers regardless of their physical location. The isolation between the private and public networks maintains security and ensures consistent bandwidth performance,

Service providers can deploy an MX Series router as a broadband network gateway (BNG) within their network, and then deploy the BNG as a WAG. Figure 1 shows a sample topology.

Figure 1: MX Series Router Deployed as a WAG MX Series Router Deployed as a WAG

After deploying a WAG, service providers can configure the WAG to provide secure wireless connectivity for devices such as computers, laptops, tablets, gaming systems, and mobile phones.

WAG offers wireline and mobile service providers the following deployments and business value opportunities:

  • Wireline service providers–The WAG deployment is based on an in-home division of access points or public access points, and works with any Wi-Fi access point that creates a generic routing encapsulation (GRE) tunnel to the MX Series router. This deployment protects subscribers and reduces churn by offering free Wi-Fi with a paid wireline subscription. For added value, service providers can also sell ad hoc access or mode, such as airport, public safety, search-and-rescue, and café access.

  • Mobile service providers–The WAG deployment is based on the mobile service provider’s own access points, or wholesale and retail with the wireline service provider. Service providers that offer quadruple play, where TV, Internet, wireless, and landline phone services are combined, can leverage both wireline and wireless assets. This deployment helps reduce costs in mobile packet core and radio access network infrastructures by offloading mobile data through Wi-Fi access points. This approach reduces congestion on licensed spectrum while maintaining user identity and associated services, and expands overall service coverage. With a trusted Wi-Fi, mobile providers can integrate hotspots into their policy and accounting infrastructure, allowing operators to maintain customer visibility on their networks and provide a seamless Wi-Fi access experience to the end user.

Subscriber services use dynamic-bridged generic routing encapsulation (soft GRE) tunnels to support WAG deployments by enabling Layer 2 traffic exchange between the customer premises equipment (CPE) and the BNG. See Wi-Fi Access Gateway Deployment Model Overview. The CPE can either be a Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE) client. Because soft GRE is stateless, the BNG removes the tunnel when the subscriber logs out and does not maintain tunnel state when no active subscriber session exists, improving scalability. The following key features are supported:

  • Dynamic creation and deletion of GRE tunnels

  • GRE tunnels on VLAN tagged and untagged interfaces

  • IPv4 and IPv6 GRE tunnels

  • VLAN tagged and untagged GRE playloads

  • IPv4 and IPv6 DHCP or PPPoE subscriber termination over GRE

The WAG supports per-subscriber services for subscribers connected through GRE tunnels, including:

  • Authentication, authorization, and accounting (AAA)

  • IP address assignment

  • Hierarchical quality of service (QoS)

  • Lawful intercept

  • Class of service (CoS)

Benefits of Wi-Fi Access Gateway

  • Authenticates Wi‑Fi users even when they are not directly connected to the WAG at Layer 2, because GRE tunnels carry Layer 2 information across an IP network.

  • Applies services based on user equipment (UE)–specific identifiers, such as the MAC address or Subscriber Identity Module (SIM) card.

  • Applies services in the network, rather than limiting them to the Wi-Fi access point.

  • Supports soft GRE or Ethernet over GRE on most Wi‑Fi access points. For Ethernet over GRE services, you need to configure only one end of the tunnel; the other end dynamically learns remote IP addresses by inspecting incoming GRE packets.

  • Improves network scalability by enabling seamless integration and supporting Layer 3 termination for user equipment (UE).

  • Supports both VLAN-tagged and untagged Ethernet frames, providing flexibility for diverse deployment conditions.

  • Supports high availability and redundancy in Wi-Fi offload conditions, allowing for reliable network performance under various operational conditions.

  • Supports retrieval of soft GRE information through Junos telemetry. To configure Junos telemetry, see Junos Telemetry Interface User Guide | Junos OS | Juniper Networks. For a complete list of soft GRE sensors and sensor path information, see Junos YANG Data Model Explorer.

Wi-Fi Access Gateway Deployment Model Overview

Figure 2 shows an MX Series router broadband network gateway (BNG) deployed as a Wi-Fi access gateway (WAG). The WAG provides a multiservice edge with a full broadband feature set that is highly reliable because of the included redundant hardware. Ethernet frames from the user equipment device must be tunneled to the BNG across an IP cloud or public Internet.

Broadband edge subscriber service over softGRE tunnel is developed to support Wi-fi Offload Gateway deployments. This integration facilitates Layer 2 transmission to user equipment (UE) through Ethernet frames encapsulated in GRE headers. The configuration supports DHCP and PPPoE dual stack access models, allowing VLAN-tagged or untagged Ethernet frames.

Figure 2: MX Series as Wi-Fi Access Gateway Deployment Model Network diagram showing Wi-Fi setup with two access points, public SSIDs linked to VLANs, GRE tunnels to IP cloud, and MX Series Gateway handling AAA, address assignment, and CoS.

To support the MX Series BNG deployed as a WAG, dynamic-bridged generic routing encapsulation (GRE) tunnels are created and terminated at the BNG when it receives GRE traffic from the wireless access point (WAP). Dynamic Host Configuration Protocol (DHCP) or PPPoE subscribers are transported through GRE tunnels as either VLAN-tagged per service set identifier (SSID) or untagged. When the user equipment device connects to the SSID and begins to send traffic, the access point initiates a Layer 2 soft GRE or Ethernet-over-GRE connection to the MX Series BNG and the BNG dynamically builds the GRE tunnel. The softGRE tunnel configuration of source IP address, destination IP network, and associated PS interface is used to enable dynamic GRE tunnel creation service. The PS interface is anchored over logical tunnel interfaces. GRE tunnels are cleared after all of the subscribers within a GRE tunnel have logged out and a configurable timer has expired. Fault tolerance and service availability is supported through the use of Layer 2 softGRE tunnel anchored on redundant GRE tunnels, ensuring continuous connectivity even in the event of a failure.

This deployment model supports a full set of services per user equipment device and per access point. Subscriber services such as authentication, authorization, and accounting (AAA); address assignment; hierarchical quality of service (QoS); lawful intercept; and class of service (CoS) are supported for individual DHCP subscribers and PPPoE subscribers within the GRE tunnels. No additional service cards are required for GRE or QoS because all features run inline on MPCs.

External RADIUS proxy supports Extensible Authentication Protocol (EAP) Subscriber Identity Module (SIM), Tunneled Transport Layer Security (TTLS), and Authentication and Key Agreement (AKA) protocols. The External RADIUS proxy also integrates with HTTP redirect to the Web portal.

The MX Series as WAG deployment model also supports the wholesale of access point access to multiple retail service providers. This wholesaling allows the local breakout of traffic or Layer 3 handoff to retail service providers.

Supported Access Models for Dynamic-Bridged GRE Tunnels on the Wi-Fi Access Gateway

DHCP and PPPoE subscriber access modules are supported for packets carried over dynamic-bridged generic routing encapsulation (GRE) tunnels. Dynamic-bridged generic routing encapsulation (GRE) tunnels and the Wi-Fi access gateway support interface stacks for VLAN-tagged and untagged subscribers. Subscriber features such as authentication, address assignment, Class of service (CoS), dynamic and service profiles for DHCP subscribers, lawful intercept, firewall filters, and change of authorization (CoA) are supported.

Scaling limitations of pseudowire subscriber interface devices (psn IFDs) require multiple tunnels to share the same psn IFD. The pseudowire is a virtual device that is stacked above the logical tunnel anchor point on the physical interface (the IFD).

The system does not allow a psn IFD used for dynamic GRE tunnel termination to service MPLS pseudowire termination. Subscriber services and lawful intercept are supported only at the IP demultiplexing (demux) interface level.

Note:

A GRE tunnel cannot have both untagged and tagged subscribers.

The tagged model and the untagged model are described in the following sections:

Dynamic VLAN-Tagged Subscribers

To simplify provisioning and troubleshooting for VLAN-tagged subscribers, configure all Wi-Fi access points to use the same set of VLANs. This configuration allows a single pseudowire subscriber logical interface (psn IFL), associated with a VLAN ID on a psn IFD, to represent multiple GRE tunnels.

A dynamic VLAN demux interface (demux0.yyyyyyyy) is created for each VLAN tag and is stacked over the tunnel psn interface (psn.xxxxxxxx). Multiple VLANs (single and dual-tagged) can exist over the same GRE tunnel. The subscribers' IP demux interfaces are then created over the VLAN demux interface.

Untagged Subscribers

The system creates untagged DHCP or PPPoE subscribers directly over the GRE tunnel. For each subscriber, it creates an IP demux interface (demux0.yyyyyyyy) stacked over the tunnel psn logical interface (psn.xxxxxxxx). The system can support multiple subscribers over the same GRE tunnel.

Wi-Fi Access Gateway Configuration Overview

To configure the MX Series router as a Wi-Fi access gateway (WAG):

  1. Configure a pseudowire subscriber logical interface device.
  2. Configure the conditions for enabling dynamic-bridged GRE tunnels.
  3. Configure the type of dynamic-bridged GRE tunnel that carries subscriber traffic to the WAG:
    Note:

    A GRE tunnel cannot have both untagged and tagged subscribers.

Configuring a Pseudowire Subscriber Logical Interface Device for the Wi-Fi Access Gateway

Before you begin, you must create a logical tunnel interface:

To configure the pseudowire subscriber logical interface device on which the dynamic-bridged GRE tunnel is built on the MX Series router Wi-Fi access gateway:

  1. Specify the pseudowire subscriber logical interface that you want to configure.
  2. Configure PS over LT or RLT

    Soft-GRE implementation uses the pseudowire infrastructure for GRE encapsulation and decapsulation. It requires the operator to configure pseudowire subscriber (PS) and logical tunnel (LT) or redundant logical tunnel (RLT) interfaces. Soft-GRE tunnels are built on the configured pseudowire subscriber interfaces. The service interface is anchored to LT interface for forwarding plane processing. To provide redundancy for the underlying forwarding path, you can also anchor the PS interface to an RLT interface by grouping multiple LT interfaces. PS over RLT supports both active-active and active-backup modes.

    1. Configure an LT interface as the anchor point for tunnel termination.
    2. To configure a PS over RLT, define the anchor point as an RLT group rlt0 and configure the RLT group with multiple LT interfaces in active/active mode.

      To configure a redundant logical interface in active/backup mode, define the anchor point as rlt0 and configure the RLT with two LT interfaces. For redundancy support, specify one LT interface as active and the other as backup.

  3. Configure three-level hierarchical scheduling on the logical tunnel interface.
  4. Configure the mixed VLAN tagging method for the pseudowire logical interface device.
    Note:

    You must configure flexible-vlan-tagging even if only untagged subscriber packets are being transported on the dynamic-bridged GRE tunnel.

  5. Specify that you want to configure unit 0, which represents the transport logical interface.
  6. Specify the Ethernet CCC encapsulation method for the transport logical interface.

Configuring Conditions for Enabling Dynamic-Bridged GRE Tunnel Creation

Before you begin:

To configure the conditions for enabling dynamic-bridged generic routing encapsulation (GRE) tunnel creation, you configure one or more GRE tunnel groups. Multiple GRE tunnel groups can have the same source-address or the same destination-networks value, but you cannot use a specific source-address and destination-networks combination in more than one GRE tunnel group.

To configure a GRE tunnel group:

  1. Name the dynamic GRE tunnel group and specify the source IP address of the GRE tunnels for the WAG. Use the IP address of the MX Series router that you configured to receive the incoming GRE traffic.
  2. Specify the IP subnets from which the system can process the GRE traffic.
  3. Specify the pseudowire subscriber interface device (IFD) to build the dynamic-bridged GRE tunnels.
  4. Specify the dynamic profile that configures the GRE tunnel.
  5. (Optional) Configure the number of seconds that a GRE tunnel remains up after the last subscriber session on the tunnel has ended.

    The default value for tunnel-idle-timeout is 120 seconds.

  6. To configure another GRE tunnel group, repeat this procedure.

Configuring VLAN Subscriber Interfaces for Dynamic-Bridged GRE Tunnels on Wi-Fi Access Gateways

To configure subscriber interfaces for VLAN-tagged Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE) subscribers on dynamic-bridged generic routing encapsulation (GRE) tunnels:

  1. Name the dynamic profile that creates the GRE tunnel.
  2. Define the interface using the predefined variable $junos-interface-ifd-name to dynamically match the receiving interface name. Also, define the logical unit for the dynamically created subscriber interface by assigning the unit number using the $junos-interface-unit predefined variable.
  3. (Optional) Enable packet reassembly for fragmented GRE packets.
  4. Define the unit family type.

    Use inet6 for IPv6 family type.

  5. Configure the interface to derive the local address from the loopback interface.
  6. Configure the router to respond to any ARP request.
  7. Configure stacked VLAN processing:
    1. Access the VLAN range configuration for stacked VLANs.
    2. Specify the dynamic profile that is used to create VLANs. When the dynamic GRE tunnel is created, this configuration will trigger subscriber management dynamic profiles to create VLANs and demux interfaces that accept DHCP or PPPoE subscribers. For more information, see Broadband Subscriber VLANs and Interfaces User Guide.
    3. Specify that the VLAN dynamic profile accepts any type of VLAN Ethernet packet.
    4. Specify the outer and inner stacked VLAN ranges that you want the dynamic profile to use.
  8. Configure single-tagged VLAN processing:
    1. Access the VLAN range configuration for single VLANs.
    2. Specify the dynamic profile used to create VLANs.
    3. Specify that the VLAN dynamic profile accepts any type of VLAN Ethernet packet.
    4. Specify the VLAN range that you want the dynamic profile to use.

Configuring Untagged Subscriber for Dynamic-Bridged GRE Tunnels on Wi-Fi Access Gateways

To configure subscriber interfaces for untagged Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over Ethernet (PPPoE) subscribers on dynamic-bridged generic routing encapsulation (GRE) tunnels:

  1. Name the dynamic profile that creates the GRE tunnel.
  2. Define the interface using the predefined variable $junos-interface-ifd-name to dynamically match the receiving interface name.
  3. Define the logical unit for the dynamically created subscriber interface by assigning the unit number using the $junos-interface-unit predefined variable.
  4. (Optional) Enable packet reassembly for fragmented GRE packets.
  5. Define the predefined variable for the underlying interface of the demux interfaces.
  6. Define the unit family type.

    Use inet6 for IPv6 family type.

  7. Configure the interface to derive the local address from the loopback interface.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
25.4R1
Starting Junos OS Release 25.4R1, you can configure conditions to enable IPv6 dynamic-bridged GRE tunnel creation.
25.2R1
Starting Junos OS Release 25.2R1, pseudowire subscriber (PS) interfaces over redundant logical tunnels (RLT) is supported for PPPoE dual stack access models with both active/active and active/backup modes. The feature supports redundancy, improving bandwidth and fault tolerance and ensuring continuous service availability.
25.2R1
Starting Junos OS Release 26.2R1, pseudowire subscriber (PS) interfaces over redundant logical tunnels (RLT) is supported for DHCP and PPPoE access models with both active/active and active/backup modes.