IP source violations occur when the PDSN receives packets from a subscriber where the source address is not the same as the address given to the subscriber, and hence get discarded. Examples and how to minimize call disconnects when this occurs.
Source violations occur when a mobile device sources packets to the PDSN with a different IP address than was originally given out by the PDSN during call setup. This is a security feature to stop the over-abundance of packets that should not be sent through the network by dropping the packets when they try to pass through the PDSN. Regardless, it is also possible that the service provider's network will have a firewall somewhere farther along that will drop packets that are not sourced from the range of known subscriber IP addresses (known because of IP pool definitions). The default behavior of the PDSN, besides dropping such packets, is to either force a PPP renegotiation or more radically to drop the call based on various criteria. Note that even if subscribers do reconnect, they will continue to be subject to the same restrictions and so possible continual termination is possible, which can be very frustrating on a subscriber basis.
The configurables mentioned below change the IP Source Violation settings for the PDSN service to be less stringent, by increasing the number of violations allowed and doing so over a shorter period of time, thereby not resulting in ppp renegotiation or call termination as easily.
To detect source violations happening for a specific subscriber, in a monitor subscriber trace, look for a source address different than what was assigned to the device originally. (“show subscriber full username/msid <username or msid>” will display the subscriber ip address in field “ip address”.) Here is an example where a source address of 188.8.131.52 (third packet) was received instead of the assigned address 184.108.40.206:
INBOUND>>>>> 20:15:42:510 Eventid:25000(0) PPP Rx PDU (49) IP 49: 220.127.116.11.1398 > 18.104.22.168.24206: S [tcp sum ok] 3577452148:35774 52148(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 40701, len 48)
INBOUND>>>>> 20:15:42:516 Eventid:25000(0) PPP Rx PDU (49) IP 49: 22.214.171.124.1399 > 126.96.36.199.80: S [tcp sum ok] 2770395692:27703956 92(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 40702, len 48)
INBOUND>>>>> 20:15:42:636 Eventid:25000(0) PPP Rx PDU (61) IP 61: 188.8.131.52 > 184.108.40.206: icmp: echo request (ttl 3, id 40703, len 60)
Note that individual violations are not tagged in the monitor subscriber output. But …
If PPP renegotiation occurs as a result of the reneg-limit being reached, you will see something like:
***CONTROL*** 20:15:42:636 Eventid:10100
IP Source Address Violation - Restarting PPP - Subscriber <firstname.lastname@example.org>, msid <621007099407072>, Bad ipv4 address 220.127.116.11 - Expected ipv4 address 18.104.22.168 - Total source violations 50
If a call actually gets dropped as a result of the drop-limit being reached, you will see something like:
***CONTROL*** 20:15:45:075 Eventid:10101 IP Source Address Violation - Dropping Call too many violations - Subscriber <email@example.com> msid <621007099407072> Bad ipv4 address 22.214.171.124 - Expected ipv4 address 126.96.36.199 - Total source violations 100
At any time during a subscriber session, you can look at the current number of violations with “show subscriber full username/msid <username or msid>”, and look for the counter "ipv4 source violations:”
At the end of a call, this information is also displayed in the “CALL STATS” of monitor subscriber as “ipv4 source violations”
Finally, a way to see source violations at the chassis level would be to look at the ppp statistics
[local]PDSN# show ppp stat | grep "source address violation:" call type detect failed: 417697 source address violation: 779327
Also, the "show session disconnect-reasons" command also counts call drops as a result of source violations as "Invalid-source-IPV4-address(27)"
The relevant configurables to control the behavior of encountering source violations are in the PDSN service, for example:
ip source-violation reneg-limit 50 ip source-violation drop-limit 100 ip source-violation period 60 ip source-violation clear-on-valid-packet
The definitions and explanations of these fields are fairly clearly explained in the CLI guide. In short, shortening the time period and increasing the reneg-limit and drop-limit values will cause the renegotiation and call drop rates to decrease.
Imported from Starent Networks Knowledgebase Article # 10920