A transit policy is associated with the parent (divert) SAP/SDP to define how transit AA subscribers are created within that parent. The transit policy must be defined in the configure application-assurance group partition transit-prefix-policy or configure application-assurance group partition transit-ip-policy context before it can be assigned to a parent. Transit IP subs can be created using the methods described in Table: Transit IP subscriber types and creation methods
| Transit IP subscriber type | Creation method |
|---|---|
|
Static |
CLI/SNMP configuration of a transit AA subscriber is done within the transit-ip-policy |
|
Dynamic |
DHCP authentication |
|
Dynamic |
RADIUS accounting to Policy and Charging Rules Function (PCRF) or AAA |
|
Dynamic |
seen-IP transit auto-create |
Transit prefix subs are created by static CLI/SNMP configuration of a transit AA subscriber within the transit-prefix-policy. The transit prefix policy follows IP filter conventions for first match and ordering of entries. While for residential /32 transits if there is an IP address conflict between any static prefix transit subs, the latter configuration is blocked, for business transit subs multiple overlapping address entries are allowed to enable longest match within subnets. IP addresses for a VPN site as an AA subscriber are configured with the transit prefix policy. There are two options:
aa-sub-ip is used when the site is on the same side of the system as the parent SAP.
network-ip is used when the site is on the same opposite of the system as the parent SAP.
A transit prefix subscriber may only have either aa-sub-ip entries or network-ip entries but not both.
The IP addresses defined in the transit-ip-policy for a transit sub are full /32 IP addresses. The IP addresses defined in the transit-prefix-policy for a transit sub are any length from /0 to /32.
Multiple IP addresses (from any prefix/pool) can be assigned to a single transit AA sub. IP addresses must be unique within a transit policy, but can be re-used in separate policies (because they have parent specific context).
The transit policy contains the default app-profile for the transit sub if a transit policy is created but app-profile is not specified. An app-profile can be later explicitly assigned to the transit sub after the sub is created (using RADIUS COA, DHCP or static).
For dynamic transit IP subs, a sub-ident-policy (also used by ESM to associate sub ID policies to a SAP) can now also be associated with the AA subscriber parent by defining the sub-ident policy in the transit IP policy. This determines how sub identifying strings are derived from DHCP option 82 fields. The policy also contains app-profile-map which maps the strings to the defined app-profiles. Transit subs do not use the sla-profile or sub-profile aspects of the sub-ident-map.
In the case of multi-homed transit subs, the transit-ip-policy must be the same on both nodes of the multi-homed parent link to ensure consistency of sub context and policy.
There is no configurable limit to the number of hosts per sub (this is similar to lease-populate which limits the number of dynamic hosts per SAP) and no limit to the number of transit subs per transit IP policy (parent). This is a function of the PE doing subscriber management.
If transit sub resource limits are exceeded (hosts per sub, or subs per ISA) the transit sub creation is blocked (for both static and dynamic models).
There is a per-ISA group/partition show list of AA subscribers in a transit-ip-policy which includes a parent field for transit subs (static versus dynamic identified).
Persistent AA statistics is supported dynamic transit AA subs, ensuring that accounting usage information is not lost when the sub disconnects before reporting interval end.