Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Announcement: Our new, consolidated Junos CLI Reference is now available.

close
external-header-nav
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents

Wi-Fi Access Gateways

date_range 06-Dec-23

Wi-Fi Access Gateway Overview

Wi-Fi access gateway (WAG) provides the public with Wi-Fi access from a residential Wi-Fi network or from a business Wi-Fi network. At home, subscribers have their existing Wi-Fi network; however, a part of their network is available for the general public to use. Members of the public who have an account with the same Internet service provider as the subscriber has at home can access the Internet and mobile network through the public part of the subscriber’s Wi-Fi connection when they are in close proximity to the subscriber’s home. WAG authenticates and connects subscribers regardless of their physical location.

Starting in Junos OS Release 17.2R1, service providers can deploy the 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 WAGMX Series Router Deployed as a WAG

After a WAG has been deployed, service providers can configure the WAG to create secure wireless home network connections for computers, laptops, and other Wi-Fi electronic products (such as game systems, tablets, or 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 including 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 offsets costs in mobile packet core and radio access network infrastructures with the ability to offload mobile data. For added value, service providers can offer Wi-Fi for all devices with a mobile data place as a competitive differentiator.

Customers who purchase broadband can also receive Wi-Fi on any community Wi-Fi access point. Subscribers have a private and secure home connection, and can also access a public connection that is shared by other subscribers. To maintain a level of security and protect the private home connection, the two networks are separated. This separation ensures a strong level of bandwidth on the subscribers’ personal connections.

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 Dynamic Host Configuration Protocol (DHCP) subscribers within the GRE tunnels. Using GRE tunnels for Wi-Fi provides the following benefits:

  • Wi-Fi users who are not directly connected through Layer 2 to WAG are authenticated because GRE tunnels transmit Layer 2 information across any IP network.

  • Services based on user equipment-specific information are applied using the media access control (MAC) address or Subscriber Identity Module (SIM) card.

  • Services are applied in the network, not just at the Wi-Fi access point.

  • The soft GRE or Ethernet-over-GRE standard is supported on most Wi-Fi access points. For services using the Ethernet over GRE standard, only one side of the tunnel needs to be configured; the other end learns the remote IP addresses of all remote tunnel endpoints by examining the incoming GRE packets.

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.

Figure 2: MX Series as Wi-Fi Access Gateway Deployment ModelMX Series as Wi-Fi Access Gateway Deployment Model

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) 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. GRE tunnels are cleared after all of the subscribers within a GRE tunnel have logged out and a configurable timer has expired.

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

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 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 that multiple tunnels 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).

Note:

The psn IFD used to service dynamic GRE tunnel terminations cannot be simultaneously used to service MPLS pseudowire terminations.

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 make provisioning and troubleshooting easier for VLAN-tagged subscribers, use the same set of VLANs on all of the Wi-Fi access points. Doing this requires that the same pseudowire subscriber interface service logical interface (psn IFL) (associated with a VLAN ID) on a psn IFD represents 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). There can be multiple VLANs (single and dual-tagged) over the same GRE tunnel. The subscribers' IP demux interfaces are then created over the VLAN demux interface.

Untagged Subscribers

Untagged DHCP subscribers can be created directly over the GRE tunnel. For each subscriber, an IP demux interface (demux0.yyyyyyyy) is created and is stacked over the tunnel psn logical interface (psn.xxxxxxxx). There can be 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 that you want to configure the pseudowire subscriber logical interface device.
    content_copy zoom_out_map
    user@host# edit interfaces psn 
    

    For example:

    content_copy zoom_out_map
    user@host# edit interfaces ps0 
    
  2. Specify the logical tunnel interface that is the anchor point for the pseudowire logical device interface.
    content_copy zoom_out_map
    [edit interfaces psn]
    user@host# set anchor-point lt-fpc/pic/port 
    

    For example:

    content_copy zoom_out_map
    [edit interfaces ps0]
    user@host# set anchor-point lt-0/0/0 
    
  3. Configure three-level hierarchical scheduling on the logical tunnel interface.
    content_copy zoom_out_map
    [edit interfaces lt-fpc/pic/port]
    user@host# set hierarchical-scheduler implicit-hierarchy 
    

    For example:

    content_copy zoom_out_map
    [edit interfaces lt-0/0/0]
    user@host# set hierarchical-scheduler implicit-hierarchy 
    
  4. Configure the mixed VLAN tagging method for the pseudowire logical interface device.
    content_copy zoom_out_map
    [edit interfaces psn]
    user@host# set flexible-vlan-tagging 
    
    Note:

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

    For example:

    content_copy zoom_out_map
    [edit interfaces ps0]
    user@host# set flexible-vlan-tagging 
    
  5. Specify that you want to configure unit 0, which represents the transport logical interface.
    content_copy zoom_out_map
    [edit interfaces psn]
    user@host# edit unit 0 
    

    For example:

    content_copy zoom_out_map
    [edit interfaces ps0]
    user@host# edit unit 0 
    
  6. Specify the Ethernet CCC encapsulation method for the transport logical interface.
    content_copy zoom_out_map
    [edit interfaces psn unit 0]
    user@host# set encapsulation ethernet-ccc 
    

    For example:

    content_copy zoom_out_map
    [edit interfaces ps0 unit 0]
    user@host# set encapsulation ethernet-ccc 
    

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 on the MX Series router WAG, 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.
    content_copy zoom_out_map
    [edit services]
    user@host# set soft-gre group-name 
    

    For example:

    content_copy zoom_out_map
    [edit services]
    user@host# set soft-gre AP-Group1 
    
  2. 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.
    content_copy zoom_out_map
    [edit services soft-gre group-name]
    user@host# set source-address wag-ip-address 
    

    For example:

    content_copy zoom_out_map
    [edit services soft-gre AP-Group1]
    user@host# set source-address 192.168.0.20 
    
  3. Specify the IP subnets from which GRE traffic can be processed.
    content_copy zoom_out_map
    [edit services soft-gre group-name]
    user@host# set destination-networks [prefix] 
    

    For example:

    content_copy zoom_out_map
    [edit services soft-gre AP-Group1]
    user@host# set destination-networks 192.0.2.0/24 
    
  4. Specify the pseudowire subscriber interface device (IFD) on which to build the dynamic-bridged GRE tunnels.
    content_copy zoom_out_map
    [edit services soft-gre group-name]
    user@host# set service-interface psn 
    

    For example:

    content_copy zoom_out_map
    [edit services soft-gre AP-Group1]
    user@host# set service-interface ps0 
    
  5. Specify the dynamic profile that configures the GRE tunnel.
    content_copy zoom_out_map
    [edit services soft-gre group-name]
    user@host# set dynamic-profile profile-name 
    

    For example:

    content_copy zoom_out_map
    [edit services soft-gre AP-Group1]
    user@host# set dynamic-profile tunnel_profile 
    
  6. (Optional) Configure the number of seconds that a GRE tunnel remains up after the last subscriber session on the tunnel has ended.
    content_copy zoom_out_map
    [edit services soft-gre group-name]
    user@host# set tunnel-idle-timeout seconds 
    

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

    For example:

    content_copy zoom_out_map
    [edit services soft-gre AP-Group1]
    user@host# set tunnel-idle-timeout 60 
    
  7. 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) subscribers on dynamic-bridged generic routing encapsulation (GRE) tunnels:

  1. Name the dynamic profile. that creates the GRE tunnel
    content_copy zoom_out_map
    [edit]
    user@host# set dynamic-profiles profile-name 
    

    For example:

    content_copy zoom_out_map
    [edit]
    user@host# set dynamic-profiles tunnel_profile 
    
  2. Define the interface with the internal variable used by the router to match the interface name of the receiving interface.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name]
    user@host# edit interfaces $junos-interface-ifd-name 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles tunnel_profile]
    user@host# edit interfaces $junos-interface-ifd-name 
    
  3. Define the unit with the internal variable.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name]
    user@host# set unit $junos-interface-unit 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name]
    user@host# set unit $junos-interface-unit 
    
  4. (Optional) Enable packet reassembly for fragmented GRE packets.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set reassemble-packets 
    
  5. Define the unit family type.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set family (inet | inet6) 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set family inet 
    
  6. Enable the local address for the interface to be derived from the loopback interface address.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit family (inet | inet6)]
    user@host# set unnumbered-address lo0.0 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit family inet]
    user@host# set unnumbered-address lo0.0 
    
  7. Configure the router to respond to any ARP request.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set proxy-arp 
    
  8. Configure stacked VLAN processing:
    1. Access the VLAN range configuration for stacked VLANs.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
      user@host# edit auto-configure stacked-vlan-ranges 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit]
      user@host# edit auto-configure stacked-vlan-ranges 
      
    2. Specify the dynamic profile that is used to create VLANs.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure stacked-vlan-ranges]
      user@host# edit dynamic-profile profile-name 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure stacked-vlan-ranges]
      user@host# edit dynamic-profile auto_svlan_demux 
      
    3. Specify that the VLAN dynamic profile accepts any type of VLAN Ethernet packet.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure stacked-vlan-ranges dynamic-profile profile-name]
      user@host# set accept any 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure stacked-vlan-ranges dynamic-profile auto_svlan_demux]
      user@host# set accept any 
      
    4. Specify the outer and inner stacked VLAN ranges that you want the dynamic profile to use.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure stacked-vlan-ranges dynamic-profile profile-name]
      user@host# set ranges low-tag-high-tag,low-tag-high-tag 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles  tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure stacked-vlan-ranges dynamic-profile auto_svlan_demux]
      user@host# set ranges 1000-1100,1200-1300 
      
  9. Configure single-tagged VLAN processing:
    1. Access the VLAN range configuration for single VLANs.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
      user@host# edit auto-configure vlan-ranges 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit]
      user@host# edit auto-configure vlan-ranges 
      
    2. Specify the dynamic profile used to create VLANs.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure vlan-ranges]
      user@host# edit dynamic-profile profile-name 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure vlan-ranges]
      user@host# edit dynamic-profile auto_vlan_demux 
      
    3. Specify that the VLAN dynamic profile accepts any type of VLAN Ethernet packet.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure vlan-ranges dynamic-profile profile-name]
      user@host# set accept any 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure vlan-ranges dynamic-profile auto_vlan_demux]
      user@host# set accept any 
      
    4. Specify the VLAN range that you want the dynamic profile to use.
      content_copy zoom_out_map
      [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure vlan-ranges dynamic-profile profile-name]
      user@host# set ranges low-tag-high-tag 
      

      For example:

      content_copy zoom_out_map
      [edit dynamic-profiles tunnel_profile interfaces $junos-interface-ifd-name unit $junos-interface-unit auto-configure vlan-ranges dynamic-profile auto_vlan_demux]
      user@host# set ranges 1-50 
      user@host# set ranges 101-150 
      

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

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

  1. Name the dynamic profile that creates the GRE tunnel.
    content_copy zoom_out_map
    [edit]
    user@host# set dynamic-profiles profile-name 
    

    For example:

    content_copy zoom_out_map
    [edit]
    user@host# set dynamic-profiles tunnel_demux 
    
  2. Define the interface with the internal variable used by the router to match the interface name of the receiving interface.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name]
    user@host# edit interfaces $junos-interface-ifd-name 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles tunnel_demux]
    user@host# edit interfaces $junos-interface-ifd-name 
    
  3. Define the unit with the internal variable.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name]
    user@host# set unit $junos-interface-unit 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles  tunnel_demux interfaces $junos-interface-ifd-name]
    user@host# set unit $junos-interface-unit 
    
  4. (Optional) Enable packet reassembly for fragmented GRE packets.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set reassemble-packets 
    
  5. Configure the variable for the underlying interface of the demux interfaces.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set demux-options underlying-interface $junos-underlying-interface 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles  tunnel_demux interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set demux-options underlying-interface $junos-underlying-interface 
    
  6. Define the unit family type.
    content_copy zoom_out_map
    [edit dynamic-profiles profile-name interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set family (inet | inet6) 
    

    For example:

    content_copy zoom_out_map
    [edit dynamic-profiles   tunnel_demux interfaces $junos-interface-ifd-name unit $junos-interface-unit]
    user@host# set family inet 
    

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
17.2R1
Starting in Junos OS Release 17.2R1, service providers can deploy the MX Series router as a broadband network gateway (BNG) within their network, and then deploy the BNG as a WAG.
external-footer-nav