Cisco ASR 5000 Series Administration Manual page 56

Enhanced charging services
Hide thumbs Also See for ASR 5000 Series:
Table of Contents

Advertisement

▀ Enhanced Features and Functionality
3. Shallow/Deep Packet TCP Analysis (support for TCP OOO)
4. Stateful Firewall Processing
5. Application Detection and Control Processing
6. DPI Analysis
7. Charging Function (including rule-matching, generation of various records, and applying various
 Egress Data Flow from Proxy: All egress data flow is generated at proxy stack. For uplink packets, egress data
flow would involve the following and then are sent out of the chassis:
1. IP Analysis
2. Shallow/Deep Packet TCP Analysis
3. Stateful Firewall processing
4. Network Address Translation processing
For downlink packets, egress data flow would involve the following and then are sent out of the chassis:
1. IP Analysis
2. Shallow/Deep Packet TCP Analysis
3. Stateful Firewall processing
On enabling TCP Proxy the behavior of some ECS features will get affected. For flows on which TCP Proxy is enabled
it is not necessary that all the packets going out of the Gn (or Gi) interface are the same (in terms of number, size, and
order) as were on Gi (or Gn).
 IP Reassembly: If the fragments are successfully reassembled then DPI analysis is done on the reassembled
packet.
Without TCP Proxy, fragmented packets will go out on the other side. With TCP proxy, normal (non-
fragmented) IP packets will go out on the other side (which will not be similar to the incoming fragmented
packets).
With or without TCP Proxy, if fragment reassembly was not successful, then all the fragments will be dropped
except under the case where received fragments were sufficient enough to identify the 5-tuple TCP flow and
the flow had TCP Proxy disabled on it.
 TCP OOO Processing: Without TCP Proxy if it is configured to send the TCP OOO packets out (as they come),
without TCP proxy such packets were sent out. With TCP Proxy, OOO packets coming from one side will go
in-order on the other side. For proxied flows TCP OOO expiry timer will not be started and hence there will be
no specific handling based on any such timeouts. Also, TCP OOO packets will not be sent to other side unless
the packets are re-ordered.
In releases prior to 14.0, when TCP Out-of-Order (OOO) packets were received and when there was any error
in buffering those packets at ECS due to memory allocation failure, these packets were marked as TCP error
packets and the rule matching was done accordingly. These packets were also marked as TCP error packets
when the reordering packet was not received before the OOO timeout.
In 14.0 and later releases, in the above mentioned scenarios, the packets are not considered as TCP error and
the TCP error flag is not set for OOO packets. So, these packets will not match TCP error related ruledef but
match other appropriate ruledefs.
If the customer has configured TCP error related rules, then OOO timeout failure packets and memory
allocation failure packets will not match these rules now. It will match normal TCP rules.
 TCP Checksum Validation: Without TCP Proxy TCP Checksum validation is optional (configurable through
"transport-layer-checksum verify-during-packet-inspection tcp" CLI command). With TCP Proxy TCP
▄ Cisco ASR 5x00 Enhanced Charging Services Administration Guide
56
configured actions)
Enhanced Charging Service Overview

Advertisement

Table of Contents
loading

Table of Contents