⚠️ Modernization Notice This post is based on notes I took in 2018 against Cisco IOS XE / ISG on the ASR 1000. The VRF placement rules and the MPLS-VPN restriction described here reflect the behavior I observed at the time. Treat the specifics as a record of what I tested, and validate against the current IOS XE ISG configuration guides before deploying.
Background
On the ASR 1000, ISG (Intelligent Services Gateway) handles subscriber web logon — the “captive portal” experience where an unauthenticated subscriber’s HTTP traffic is intercepted and redirected to a login or service-selection portal. Two ISG features work together to make this happen:
- Layer 4 Redirection transparently redirects subscriber TCP traffic (typically HTTP on port 80) to a portal server. For unauthenticated subscribers, an
L4_REDIRECTservice is applied so their browser lands on the portal instead of the requested site. - Port-Bundle Host Key (PBHK) solves the subscriber-identification problem at the portal. The ISG performs NAT/PAT on the redirected TCP traffic, rewriting the source to a configured ISG IP address and a bundle of source ports allocated per subscriber. The combination of that ISG source IP and the port bundle — the host key — uniquely identifies the subscriber to the portal, even when subscribers have overlapping or private (NATed) addresses. The host key is carried back to the portal in the RADIUS Subscriber-IP VSA.
In short: L4 redirect gets the subscriber to the portal, and PBHK lets the portal figure out which subscriber it is talking to. The piece that makes this awkward in real networks is that the subscriber and the portal frequently live in different VRFs, and PBHK has to bridge them.
VRF Placement Scenarios
The subscriber session, the PBHK interface, and the portal can sit in different VRFs. These are the combinations I found workable:
| Subscriber | PBHK interface | Portal | Notes |
|---|---|---|---|
| Global | Global | Global | Baseline — everything in the global table. |
| VRF A | VRF A | VRF A | Portal and the PBHK router must be connected on the same device. |
| VRF A | Global | Global | Subscriber in a VRF, PBHK and portal in global. Needs a static route (see below). |
Restriction: No MPLS-VPN-Tagged Portal Traffic
For the second scenario (everything in VRF A), there is an important restriction:
ISG does not support MPLS VPN-tagged traffic coming from the portal. If the PBHK interface and the portal are both in a VRF, the portal must be directly connected to the PBHK router — you cannot reach it across an MPLS L3VPN core. This is the constraint that forces the “same device” note in the table above.
Reaching a Global Portal from a VRF Subscriber
In the third scenario, the subscriber is in VRF A but the portal sits in the global routing table. There is no route to the portal inside the subscriber VRF, so you have to leak one in. A static route with a global next hop does the job:
| |
The trailing global keyword is what makes the VRF look up its next hop in the global table.
Port-Bundle on the Backbone Interface
One more piece that is easy to miss: the port-bundle command has to be applied on the backbone / MPLS-facing interface as well, not only on the subscriber side. Without it, the host-key NAT mapping does not get applied to the traffic leaving toward the portal, and subscriber identification breaks.
Where This Fits
PBHK and L4 redirection are the web-logon corner of ISG on the ASR 1000. If you look at the base control policy in my ASR 1000 Parameterized QoS post, you’ll see it already references a service-policy type service name PBHK at session-start — this post is the explanation behind that line. For the scaling side of the same platform, see Preventing ISG Session Storms.
References
- Configuring ISG Port-Bundle Host Key — IOS XE
- Configuring ISG Policies for Regulating Network Access
- ISG L4 Redirect / Web Logon overview
The content of this post was created by the author; AI was used for editing and restructuring.