13. virtual Residential Gateway
13.1. virtual Residential Gateway Overview
A virtualized residential gateway transforms the Layer 3 routed Residential Gateway (RGW) in the home into a bridged Residential Gateway, by moving the Layer 3 functions of an RGW into the network resides on a node hereby referred to as a “virtual Residential Gateway” (vRGW). The Layer 3 functionality, such as address management (DHCP server, and static or sticky address assignment), routing, Internet connectivity, NAT, UPnP, Firewall and application awareness provides functions such as URL filtering and parental control, is moved to the network and resides on the vRGW. The Residential Gateway then operates in a bridged mode and performs local switching of intra-home traffic that originates and terminates on devices within the home. Bridged traffic destined for outside the home (such as to the Internet, or to the provider’s content, or to another home) over the WAN toward the vRGW is hereby referred to as a Bridged Residential Gateway (BRG).
This mode of operation allows an operator visibility of the connected devices on the home LAN, instead of just a single IP address per home as is the case for a Layer 3 routed Residential Gateway. This allows operational improvements through per-device control and troubleshooting, and the ability to offer new services faster and on a more granular device specific-basis.
The router, as a dedicated gateway or as a BNG, serves as a vRGW providing Layer 3 termination and ESM functionality for bridged homes, as shown in Figure 183.
Figure 183: Virtualized Residential Gateway (vRGW)
13.1.1. Access Modes
All vRGW functionality is supported on both regular group interfaces (SAPs, LAGs, PW-SAPs, and so on) and WLAN GW group interfaces (soft-GRE, soft-L2TPv3, VLAN).
A new configuration sub-node for the BRG is provided under the group-interface context for regular group interfaces and under the vlan-range context for WLAN-GW group interfaces. A regular group interface with a BRG sub-node does not support any non-BRG configuration and must operate in the ipoe-bridged mode.
In a WLAN-GW group interface, the BRG is configured in the vlan-range level. With a vlan-range it is not possible to mix BRG and other existing functionalities, but it is possible to mix BRG and other functionalities (such as WLAN-GW) on the same group interface. If a BRG also supports public WIFI, the expectation is that the BRG will have different SSIDs for public WIFI and for private home traffic on the BRG, each represented by a different VLAN tag.
Contrary to WLAN-GW UEs, which require anchoring based on their MAC addresses (for mobility), devices associated with a BRG are anchored based on the tunnel source IP address of the BRG. The system therefore load-balances on a per-BRG granularity basis across a set of configured ISAs. Anchoring based on the source IP address of the BRG allows all devices in the home to be anchored on the same ISA and IOM. This enables aggregate QoS functionality within a single home.
Tunnel QoS is not supported as this will be performed by regular subscriber QoS in the BRG scenario. WLAN-GW IOM (N:M) redundancy is supported. Data-triggered authentication (IPv4 only) is supported. All WLAN-GW access types (GRE, L2TPv3, L2-AP) are supported.
13.1.2. Home Context on the vRGW
The system keeps a management context for each connected home or BRG, which is identified by a BRG ID. This context is used for authentication, configuration, and retrieval of operational data. Authentication can be performed explicitly by the BRG, in which case the vRGW acts as a RADIUS proxy. Alternatively, the vRGW can implicitly authenticate on the BRG’s behalf when the first host from the BRG connects.
Initial configuration parameters are provided as RADIUS attributes during authentication. Configuration parameters provided on the home level will be used as defaults on the host level can be overridden on a per-host basis. Home-level configuration can be dynamically overridden by means of a RADIUS CoA message. For more details on the available configuration parameters, see the vRGW section in the RADIUS Attributes Reference Guide.
Operational data provides information on the BRG such as the number of connected devices, how long the BRG has been active, and which configuration parameters were provided. This can be retrieved via MIBs or show commands.
The vRGW communicates with a classic AAA server mainly to perform the authentication and with a separate configuration/operational platform. This separate configuration/operational platform referred to as a “controller” and can be combined in a single management control system.
13.1.2.1. Implicit Home Authentication
with implicit home authentication (see Figure 184), the vRGW will authenticate a new BRG when the first associated device connects. In order to not impose restrictions on the connectivity model, the vRGW will not try to identify a BRG based on tunnel or VLAN data. The vRGW will always perform authentication of a new host and this authentication should return the BRG ID with which this host is associated. If this BRG ID is not yet known, the vRGW will trigger BRG-level authentication. This allows an operator flexibility to identify a home. For example, one deployment might use CVLANs as an identifier while another might use a BRG MAC as an identifier.
A home can be optionally authenticated with an AAA server. Each device in the home, on the other hand, is not typically authenticated with an AAA server, but merely authorized with a controller (via regular RADIUS messages and configured authentication policy) to get its configuration. This authorization is handled by the controller, which will identify and return the associated BRG ID and, optionally, any device-level configuration.
Per-home authentication is forwarded to the AAA server to be fully authenticated. In this case, it is expected that the controller performs an AAA proxy functionality so it can insert home configuration data in the final Access-Accept message. After both device and BRG authentication have been completed the resulting RADIUS attributes will be used to set up all required ESM objects (hosts, subscribers, SLA profile instances, filters, and so on).
Figure 184: Implicit Home Authentication
13.1.2.2. Explicit Home Authentication
With explicit home authentication (see Figure 185), the BRG authenticates itself at boot time before allowing connectivity of any devices. The vRGW will act as a proxy for this authentication, and upon receipt of a successful authentication, the BRG context will be created and store all home parameters. As with implicit authentication, the vRGW performs authentication for each device and expects the BRG ID as a result.
Figure 185: Explicit Home Authentication
On the router, this functionality is obtained by including a RADIUS proxy in the vRGW configuration. This RADIUS proxy can be used for both WLAN-GW and vRGW scenarios and will determine the difference based on the presence of a BRG-ID attribute in the Access-Accept message. Proxy transactions in the context of a BRG will not be cached. Instead, a fully functional BRG context will already be created. Track accounting is not supported in the context of a BRG. Reauthentication is supported and behaves the same as on a CoA at the BRG level.
13.1.2.3. Change of Configuration
It is possible to change the configuration on a home level with the use of a RADIUS CoA. The CoA should use the BRG ID as a key and contain attributes for all new or updated parameters. For all correctly specified parameters, the vRGW will overwrite the existing configuration on the home level and update all devices connected to the BRG.
13.1.2.4. Home Lifetime
A configurable ping based on a smart connectivity-verification mechanism is provided to detect whether a BRG is alive. The BRG state is removed if it is not deemed alive (subject to a configurable hold time). A BRG is always considered to be alive as long as there are connected non-static devices. Static devices are not considered because there is no control plane to track whether they are alive or not. When no sessions are present, the home context can still be in one of the following three states.
- On explicit authentication, where there is no session connected yet, the BRG state should be kept alive. To handle this, an initial hold time applies during which the BRG context cannot be removed. Any connected device will cancel the timer. If the timer expires and there are still no connections present, the BRG fall backs to the behavior as if the last session was removed.
- If the last session was removed and connectivity verification is configured, the vRGW will try to ping the BRG. This ping mechanism uses ICMP or ICMPv6 ping toward the tunnel source IP or, if not present, toward the RADIUS source IP address. As long as the pinging is successful, the BRG context is kept. If the pinging is unsuccessful or impossible to perform (such as no IP known), the BRG falls back to the hold time. If during the connectivity verification a host connects to the BRG, the verification is stopped and the BRG is assumed to be alive again.
- If the last session was removed and connectivity verification failed or was not configured, a configurable hold time applies during which time the BRG is not removed. If during the hold time a new device connects, the timer is canceled. If the timer is not canceled, the BRG is removed when the timer expires. The configured hold time can be zero and can be different from the initial hold time.
13.1.3. Device Context on the vRGW
The router maps every device in a home to an IPoE session, which can contain one or more ESM hosts depending on the number of IP stacks active on the device. The vRGW will still authorize every single device and store the resulting configuration data with the IPoE session. Whenever the session is created or updated, the vRGW will combine the configuration data of the home context with the configuration data of the device. When the same configuration object is present on both levels, the device level will apply. The resulting combined configuration data will be used to install or update the ESM objects.
13.1.4. Dynamic Configuration Changes
It is possible to dynamically change the configuration on both the home level and the device level by means of a RADIUS CoA. A CoA on the home level should use the BRG ID as key. The included attributes will overwrite the existing stored configuration on the home level and subsequently update all devices connected to the home. All devices will pick up the new home-level configuration unless a more specific configuration exists on the device level.
A CoA on the device level can use all existing ESM keys as detailed in the RADIUS Attributes Reference Guide. This will update the existing configuration on the device level. If the device inherited the specified parameter from the home level, this parameter will only be updated on the device level; the existing home-level configuration will stay intact and will be used as the default for other devices.
In certain cases, the configuration can be removed on the device level to be able to fall back to the home level. To support this, the RADIUS attribute Alc-Remove-Override has been created. This attribute lists which overrides must be removed on the session level and fall back (revert) to the home-level configuration. If the home parameter changes, the device will also pick up this new configuration.
For more details on RADIUS configuration attributes, refer to the RADIUS Attributes Reference Guide.
13.1.5. Per-Home Pool Management and L2-Aware NAT
This feature allows the provisioning of a DHCP pool per home in a vRGW context. The addresses in a per-home pool are unique, so local bridging within the home functions. Devices in different homes can, however, be allocated the same address. L2-Aware NAT is then used to handle address translation and connectivity toward the network and between homes. Per- home default GW, subnet and address range (out of which addresses are allocated to home devices) can be configured via the CLI. The address range can be overridden from RADIUS. The subnet associated with the home pool must be within the configured L2-Aware inside subnet. L2-Aware source NAT can optionally be combined with destination NAT to support enhanced traffic redirection (such as for stateful DNS overwrite function). More details on network address translation forwarding can be found in the Multiservice Integrated Service Adapter Guide.In addition to the IPv4 addresses from the home pool, the following hosts can be set up:
- IPv4 DHCP proxy hosts using an AAA-provisioned addressNote that only non L2-Aware hosts can get a framed IP address from RADIUS
- IPv6 SLAAC hosts using an AAA-provisioned address or a Local Address Assignment
- IPv6 IA_NA hosts using DHCPv6 relay, an AAA-provisioned address, or a Local Address Assignment
13.1.5.1. Sticky IP Addresses
The vRGW can be programmed with a list of sticky IP addresses per BRG. A sticky IP address is an IPv4 address from the home pool allocation range that is set aside for a specific device based on the MAC address and will never be allocated to any other device. This can be used for devices where a persistent IP address is desirable but configuring a static IP address on the device is too cumbersome (such as a network printer). The device will still use DHCP to gain connectivity but will always be assigned the same IP address.Public (non-NAT) sticky IP addresses are not directly supported in pool management but can be provisioned in the following manner.
- Create a local DHCP server and pool to manage the public address space.
- For each public sticky IP address that must be provisioned, create a sticky lease in this pool. Refer to DHCP Address Reservation for Sticky Leases for further details. Both the user identification and hostname can be the MAC address of the associated device.
- When the device linked to the sticky lease authorizes with the controller, it returns the allocated address as a framed IP address. This address will take precedence over any home pool configuration and a DHCP proxy host will be installed.
13.1.5.2. Managed Static IPv4 Addresses
Similar to sticky IP addresses, the vRGW can be programmed with a list of static IP addresses per BRG. However, for static IP addresses, DHCP is not expected from clients and will be dropped. The vRGW will automatically install all of these addresses as IPv4 hosts contained in IPoE sessions. Because every host must be linked to a specific point of access (such as a SAP or tunnel) the vRGW does need to wait on a data-trigger or the first non-static host in a home before static hosts can be created. Similar to regular (DHCP-triggered) hosts, a device-level authorization will be performed for each static host in order to retrieve the per-device level configuration.This type of static host can cover both private (inside the home subnet) and public (non-L2-Aware NAT) addresses. The created hosts can only be explicitly removed by the management interface, and mechanisms such as session-timeout and idle-timeout are not supported.
13.1.5.3. DMZ
A single DMZ address can be provisioned per home via RADIUS (VSA Alc-DMZ-Address), which can be any address inside the home subnet except for the default gateway. When a host exists with this address, the DMZ mode will be activated. Note that DMZ will be activated if a host exists with the address and the subscriber uses only 1 port range per IP. Without DMZ mode enabled, any traffic arriving for the NAT outside IP that does not match an existing flow, pinhole, or port-forward, will be dropped. With DMZ mode enabled, this traffic will be forwarded to the provisioned DMZ host.
13.1.6. IPv6
The vRGW feature set supports the following IPv6 host types:
- IPv6 SLAAC hosts using an AAA-provisioned address or a Local Address Assignment.
- IPv6 IA_NA hosts using DHCPv6 relay, an AAA-provisioned address, or a Local Address Assignment.
The vRGW only operates in IPoE bridge mode. For regular group interfaces, IPoE bridge mode must be explicitly enabled before the BRG can be enabled. For WLAN-GW group interfaces, IPoE bridge mode is implicitly assumed for a VLAN the range with BRG enabled. This has the following consequences:
- SLAAC hosts from the same home can share a /64 prefix.
- When a local address assignment is used, SLAAC hosts from the same home are automatically assigned the same /64 prefix.
- IA_NA hosts from the same BRG can get unique addresses from a shared /64 prefix. This prefix is automatically signaled in an RA.
13.1.7. QoS and Filter Support
The vRGW is based on existing ESM QoS configurations on the router where each home maps to a single subscriber instance. Home-level bandwidth can be provided by an aggregate rate or scheduler policy on the subscriber level. Groups of home devices (such as telephones, computers, televisions, and security systems) can be given a shared bandwidth by assigning a different SLA profile per such group. Individual device-level QoS can be provisioned by mapping a specific device to a specific forwarding class using IP classifiers based on the device IP. This forwarding class can then be mapped to its own individual queue. Dynamic QoS overrides can be provisioned on both the home level and the device level. While QoS overrides are represented by a single RADIUS attribute, the device level does not override the whole attribute but only the QoS objects specified on that level. For example, if on the home level, the scheduler bandwidth is overridden, and on the device level, queue bandwidth is overridden. The resulting override is a combination of both.
13.1.8. Data-Triggered Authentication
ISA-based IPv4 data-triggered authentication (Figure 186) and host creation is supported on WLAN-GW group interfaces. When authenticating a data-triggered device, the controller has less data to derive the BRG from connection data only unlike DHCP where the BRG can insert its identifier, such as a circuit-id. For pure Layer 2 access, a BRG ID can be hard-coded to a port and VLANs, although for tunneled access, this is not always possible as the corresponding value would be the tunnel source IP address . This IP address can be dynamically assigned and changed with a BRG reboot. The following alternatives are suggested.
- Use AP MAC as the identifier. This can be signaled in DHCP and DHCPv6 as specified in WIFI Aggregation and Offload. For data-trigger purposes, it can also be sent as part of the L2TPv3 header or if a GRE, it can be learned upon data-trigger via an ARPoGRE/NDoGRE message.
- Use a custom identifier that is sent in DHCP in a circuit-id option or a vendor-specific option. While a DHCP lease is active, a controller keeps state to map the device MAC to the BRG identifier in order for the data-trigger can be handled.
If the data-triggered device is the first device to come up in the home and the BRG did not perform explicit authentication, the vRGW will also trigger an implicit authentication. After authentication, two possibilities exist to install the data-triggered host.
- It is determined that the data trigger was for a static IP address. This is usually the case when the static device is the first to send upstream data in the home. In this case, the triggering static host and any other provisioned static hosts will installed.
- The trigger was sent for a dynamic host (sticky/not sticky). This usually occurs when connection with a device was lost (based on an idle-timeout) but the lease was still valid. A DHCP lease will be re created using the provisioned lease time (on the home level). This installed lease time is usually excessive compared to the actual remaining lease time on the device, but this is corrected when the lease performs DHCP renew or rebind procedures.Note however the actual remaining lease time will be used if known. Normally if a host goes idle and sends a data trigger, the actual remaining lease time will be used.
Figure 186: Data-Triggered Authentication
13.1.9. Per-Host NAT Port Ranges
Carriers want to offer opt-in value-added services (VASs) through dedicated DPI-based appliances or VMs in data-centers. This functionality requires vRGW support to forward traffic (ideally, only for subscribers who have subscribed to the VAS) to the external appliance. The appliance implements per-subscriber and per-device policies, and must be able to determine the subscriber and device from the received packets. Because address space across homes can overlap, subscriber-aware NAT is a requirement in the vRGW architecture. When subscriber-aware NAT is used, the outside IP address is unique and corresponds to the subscriber but, by default, the device information is lost. However, the device can be determined for the external appliance from the Layer 3 packet if a unique NAT outside port range is used per device on the vRGW.
By default, the subscriber-aware NAT allows the entire port range (other than the port range for static port forwarding) to be available for dynamic NAT flows and dynamic port forwarding (via UPnP). The feature adds support for allocating per-host NAT outside port ranges, and reporting per-host port-range allocation and deallocation in RADIUS accounting. External VAS appliances can then track RADIUS accounting to determine device to port-range mapping.
The port range for a host is allocated and deallocated when the host is created and deleted, respectively. A single port range per host is supported. The RADIUS attribute Alc-Per-Host-Port-Range provides the count of ports per host for a subscriber. Refer to the RADIUS Attributes Reference Guide for information about the attribute format. In case of multiple NAT policies per subscriber, the attribute value is required to be the same for all policies.
The presence of the VSA implicitly enables the per-host NAT port-range allocation mode. The ports-per-host mode is only enabled (via the VSA) if vRGW is enabled (as indicated by the presence of BRG in no-shutdown) under the VLAN range on the WLAN-GW interface, or on the group interface. The VSA can be present in access-accept for BRG authentication (implicit or explicit), and in COA (with Alc-BRG-Id as the key). If a COA is received with the Alc-Per-Host-Port-Range set to 0, it indicates the disabling of the per-host port-range mode.
In cases where the Alc-Per-Host-Port-Range VSA is changed, the flows in the overlapping region between the new and old port ranges remain intact; remaining flows (if any) are removed.
- When the ports-per-host mode is disabled (via the VSA), the new port range includes all ports except the SPFs, and in accordance with the preceding rule, no ports are deleted.
- When ports-per-host mode is enabled mid-session (via the VSA), the new port range falls within the old port range (where the old range contained all ports except the SPFs).
ISA is updated from the CPM for all hosts when the ports-per-host mode changes, and cleanup occurs in accordance with the preceding rule.
The per-host port-range is included in the Alc-Nat-Port-Range attribute in per-host or per-session RADIUS accounting (in accordance with the currently supported format of the Alc-Nat-Port-Range VSA for L2-Aware NATs).
When a new port block for a host is allocated or freed, an interim-update message with a Nat-Port-Range-Event reason is sent. The interim update is sent only when interim updates are enabled and the configured include-attributes contain the alc-port-range VSA.
The port range for a host remains allocated for the lifetime of the host (unless explicitly removed using the VSA). Per-host reserved ports (for prioritized sessions), and watermarks to indicate exhaustion of per-host port-range, are not supported.
13.1.10. Inter-Chassis Redundancy
vRGW supports stateless inter-chassis redundancy, where the home and device state is not explicitly synchronized between the two virtual residential gateways. After a redundancy switchover event, Data Triggered Authentication (DTA) is used to download the correct home and device state back from the controller.The controller should always have the latest configuration state of a given home, including any overrides after the home was activated. Additionally, the controller maintains a minimal state for DHCP pool management that can be reflected to the vRGW in case of a redundancy event. See to Figure 187.
Figure 187: Inter-Chassis Redundancy
13.1.10.1. Pool State Synchronization
Because there is no stateful synchronization between pairs of redundant gateways, all pool state is lost also in a switchover event. The new gateway creates a new pool with state information for all configured reserved and static address, but has no knowledge of dynamic addresses. When a data-triggered host is authenticated, the pool tries to recreate the lease corresponding with this source-ip. However, this is subject to race conditions. If a data-trigger is delayed (for example, the device is not active upon switchover) the DHCP pool might already have given out the IP address to a new device in the home. This not only blocks the data-trigger for the old device, but might lead to address duplication issues inside the home.To solve this issue the controller keeps track of allocated dynamic IP addresses. After a switchover event, these addresses can be sent to the vRGW as part of the BRG configuration. In this case, the per-home pool only allocates these addresses to data-triggered devices or DHCP renew triggered devices that request this specific IP address. New devices will receive addresses not present on this list. After a configurable timeout, the pool relinquishes any unclaimed IP addresses back to the pool for general use. The currently unclaimed addresses can be displayed using the following command.
It is recommended to keep the pool state on the controller simple, by marking an address as used when a device is connected and unused when it is disconnected. The controller should also periodically synchronize explicitly with the vRGW to remove addresses for which a device disconnect notification may have been lost.
13.1.10.2. Regular Group Interfaces
On regular group interfaces, redundancy is supported by enabling SRRP and IPoE session stateless redundancy. For more information on stateless redundancy see Stateful Multi-Chassis Redundancy (MCS) in the Triple Play Enhanced Subscriber Management. The backup router will always be in the backup-routing mode. There is no support for shunting traffic via a redundant interface from the backup to master router.
IPv6 traffic and public IPv4 will be attracted to the correct master router via the regular track-SRRP mechanism. L2-Aware NAT outside pools cannot use track-SRRP and should be configured distinctly on both routers making up the redundant pair. After a redundancy event, each home will gain a new outside IP address on the new master router.
Traffic from the BRGs is attracted to the correct master router via sending out Gratuitous ARP (GARP) messages. These GARPs update the FDB of the dual-homed Layer 2 aggregation nodes. This GARP is not supported for L2-Aware inside prefixes. At least one subscriber interface subnet must be explicitly configured to send a GARP.
When using MSAP deployments, the managed SAPs are not synchronized and must be recreated on the new master router via data-triggered authentication. Because there are no managed SAPs present, no GARPs can be sent when a backup router becomes master. If the aggregation node has a shared FDB for all c-VLANs (FDB per s-VLAN) or for all s-VLANs (FDB per switch), it is recommended to configure a single static SAP per s-VLAN or per port over which a single ARP can be sent.
13.1.10.3. WLAN-GW Group Interfaces
Redundancy on WLAN GW group interfaces reuses the WLAN-GW monitor route mechanism to determine active/standby state of each router in a pair of redundant routers. For more information see WLAN-GW 1:1 Active-Backup Redundancy. When using the BRG MAC as a BRG identifier, an ARPoGRE (IPv4 GRE tunnel) or NDoGRE (IPv6 GRE tunnel) is triggered when receiving a data-trigger for an unknown device. Authentication of the data trigger will be delayed until the ARP/ND is answered or timed out.
IPv6 and public IPv4 traffic from the network will be attracted to the active router because a subscriber-interface on a standby router is operationally disabled and its associated subnets are not exported to the route table. L2-Aware NAT outside pools stay active on both routers and should be configured distinctly on both routers making up the redundant pair. After a redundancy event each home will gain a new outside IP address on the new master router.
Traffic from the BRG is attracted by regular routing as only the active router will export the configured tunnel endpoints.
Access via the Layer 2 access point is not supported in a redundant setup.
Alternatively, vRGW with tunnel access also supports active and active redundancy using two different tunnel endpoint addresses. In this setup, each vRGW acts independently and does not synchronize any state. Each BRG is responsible for determining which vRGW is considered active, for example by sending ICMP/ICMP6 echo requests toward the tunnel endpoints. After detecting a failover, the BRG will direct traffic toward the alternate tunnel endpoint. The state on this vRGW will be re-created using data-trigger. This is similar to the monitor-route active/backup redundancy previously discussed. Explicit BRG authentication is supported in this use case if the BRG keeps track of a pair of tunnel endpoints and RADIUS server (proxy) addresses.
Redundancy of public IPv4 addresses and IPv6 addresses is not supported with an active/active deployment. After a failover event, it is not possible to send traffic for these addresses until the BRG restores connectivity to its original vRGW.
13.1.11. BRG and vRG Caveats
- Static IPv6 hosts are not supported in vRGW. It is possible to provide a static IPv4 host with a SLAAC prefix and use IPoE linking to automatically create an associated IPv6 host.
- Wholesale/retail is not supported in vRGW.
- Subnets provisioned for BRG pool management must lie in a pre-configured L2-Aware NAT inside prefix. The dynamic range of a BRG pool must not contain the configured L2-Aware NAT inside IP address.
- BRG connectivity verification is limited to a maximum of 50000 BRGs. If moreBRGs are connected, connectivity verification will not be performed for the excess numbers and only hold-time will apply before the BRG instance is deleted from the vRGW.
- On regular group interfaces, only a single BRG is supported per SAP.
- There is a maximum of one SLAAC prefix per BRG.
- There is a maximum of 128 IPoE sessions per BRG, and a maximum of 8 static hosts per BRG.
- There is a maximum of 32 SLAAC hosts per shared prefix.
- The idle timeout is based on SLA profile instance, not per host. For hosts under the same BRG sharing an SLA profile, it is not possible to detect early disconnect of a single host. This restriction may be fixed in a future release.
- All SLAAC hosts under a BRG sharing the same prefix will use a common forwarding context downstream. For predictable behavior, the same SLA profile should be used for each SLAAC host. This restriction may be fixed in a future release.
13.1.12. External Allocation of L2-Aware NAT Outside IP Addresses
Certain residential deployments use multiple NAT outside IP addresses on routed physical RGWs, typically one per service. This feature provides similar support for multiple NAT outside IP addresses (up to four) per BRG (in other words, per subscriber) on vRGW. These addresses fall within locally-defined NAT pools on vRGW, but are assigned and managed by an external backend system. Each NAT outside IP address typically corresponds to a service, for instance, an HSI service may be NAT’ed to a different outside IP address than the voice service.
The NAT outside IP address and the corresponding NAT policy associated with the subscriber is provided by a VSA (Alc-Nat-Outside-IPs) in the RADIUS access-accept message or the COA. Up to four instances of this VSA can be included in the RADIUS access-accept message or the COA. This provides multiple NAT outside IP addresses for a BRG. The NAT pool referred within the NAT policy must be configured for external assignment. If the provided outside IP address in the VSA does not fall in the NAT pool referenced within the corresponding NAT policy, then the outside IP address (and the mapping) is ignored. If the outside IP address falls within the NAT pool, and is not already allocated, then it is assigned to the L2-Aware subscriber. If the NAT policy contained in the VSA refers to a NAT pool that is not configured for external assignment, then the host setup fails. It is the responsibility of the external system to ensure the stickiness of the outside IP addresses for the subscriber, if needed.
The system internally chooses an ISA in the NAT group to anchor an L2-Aware subscriber, such as the ISA, to where the NAT flows for the subscriber are created based on upstream data or static port forwards. If a NAT outside IP address does not fall within the address block owned by the NAT ISA that anchors the L2-Aware subscriber, then the NAT outside IP address (/32) is added to the FDB with the ISA as the next hop. Otherwise, the downstream traffic forwarding to the NAT ISA for the L2-Aware subscriber follows the aggregate route corresponding to the address block owned by the NAT ISA.
The NAT outside IP address to use for a flow on the NAT ISA is based on a destination IP address lookup in a nat-prefix-list specified in the sub-profile for the subscriber. The nat-prefix-list contains a list of IP prefixes to NAT-policy mappings.The destination IP lookup in the nat-prefix-list provides the NAT policy to use. The NAT outside IP address that is associated with this NAT-policy is then used as the translated source IP.
All associated NAT outside IP addresses and corresponding NAT policies may dumped via the show service nat l2-aware-subscribers command.
The nat pool show command output shows the attribute that controls external assignment.