Follow these general troubleshooting suggestions when using Policy Enforcement
- If enforcement policies are not being enforced as expected, on the VLAN screen for all VLANs
set up to receive incoming subscriber traffic, verify that you set CMP
Hash to Source Address.
- If static subscriber policies are not being enforced as expected, check whether you enforced
any global high precedence policies with conflicting actions.
- When sending traffic without RADIUS, the unknown subscriber policy (if specified) is assigned
to the first flows from dynamic or static subscribers. Subscriber policies are applied to
- Policy changes are applied only to new flows. Existing flows use the same policy
- For applications with connections initiated from the Internet (FTP, RTSP, TFTP), the BIG-IP system needs to have CMP Hash set to
Destination Address on the Internet VLAN. In this case, the end-to-end
IP addresses have to be preserved, therefore SNAT should be disabled on all the virtual servers
that the applications will use.
- When importing static subscribers, the file is uploaded in chunks of 1000 subscribers. The system performs a validation check on each chunk. If a validation fails, the subscribers in the current chunk and subsequent chunks are not imported. However, the subscribers loaded in previous chunks are imported onto the system.
Use these troubleshooting suggestions for steering:
- In case of service chains (w-steering), set CMP Hash to
Source Address on all the VLANs for which the w-steering action is to
be applied. This is true only if SNAT is enabled on either the BIG-IP system or the appliance
that provides the value-added services.
- For response-side classification, steering, w-steering, and cloning actions are applied after
the results (based on destination IP address and port) are cached in the classification database (srdb). Actions are not applied for the first six flows, by default. (This
behavior is configurable by the DB variable tmm.pem.srdb.entry.step.)
Follow these troubleshooting suggestions when working with RADIUS:
- If static subscribers are not working as expected with RADIUS, check whether you selected the
same Subscriber ID Type in the radiusLB profile ( ) as that assigned when creating the static subscriber.
(IMSI in the static subscriber corresponds to 3GPP
IMSI in the RADIUS profile, E164 to Calling
Station ID, and NAI to User
- The RADIUS message also needs to specify the same Subscriber ID Type
as the RADIUS profile. So make sure that if you select IMSI, the IMSI
number exists in the RADIUS message. This also applies to the user-name
for NAI, and calling station-id for E164.
Gx interface troubleshooting
Use these troubleshooting suggestions when working with a Gx interface to PCRF:
- If you change the IP address of the Gx server in the listener, the change takes affect after
you restart TMM using the command: bigstart restart tmm.
- For Gx usage monitoring, the threshold is defined on the PCRF.
Bandwidth control troubleshooting
Here are troubleshooting suggestions for using bandwidth control with PEM:
- Do not use dynamic bandwidth control policies in preconfigured enforcement policies (either global or subscriber) when the bitrate is managed by the PCRF via PCC dynamic rules.
- Do not use dynamic bandwidth control policies in global enforcement policies if they are also used in subscriber policies.
- For bandwidth controller to work with PCRF, you need to create a default dynamic bandwidth
controller with the name dynamic_spm_bwc_policy, with eight categories named
cat1 to cat8 (all set to 100%). You must choose
a proper max-rate value for this bandwidth controller (typically, close to network capacity
dedicated to subscriber traffic). You do not have to assign this bandwidth controller to any
enforcement policy rule.