|
|
|
Measurements can be configured as one of three types:
Of these three types, the tcp measurement produces more data but is most likely to encounter access roadblocks. Because there are several distinct handshakes involved in opening and closing a TCP session and each handshake sends a new set of packets through the Internet, a single tcp measurement produces several measurements to the CNA database. Use tcp measurement when endpoints are reachable from your network and can respond to a TCP session request.
The icmp type of measurement is more likely to get through firewalls but it only contributes a single measurement to the database. Use icmp measurement when you think the endpoint will be reachable but will not respond to a TCP session request. Also use ICMP measurements when the target has limitations on the number of open TCP sessions that can be supported. For example, some VPN devices restrict the number of TCP sessions that can be opened in a given time interval. If your desired measuring frequency is greater than this restriction, then you should use ICMP measurement.
The traceprobe type is a method of last resort, for those cases where you cannot penetrate a firewall or access policy but still need to target the address in order to obtain measurements. In this case, the measurements will terminate before reaching the target, and the end-to-end delay measurements may be less complete than those obtained by the other two measurement types. This is done over UDP (at a port starting at 33434) toward the end target specified in the configuration, and measures the ICMP response from the last reachable node.
NOTE: This technique has the potential to set off intrusion detection systems - you can use commands like traceprobe retries-per-hop, traceprobe max-failing-hops, and traceprobe hops to reduce the number of packets sent.
The traceprobe measurement system has been designed to maximize measurement accuracy, minimize impact on system resources, and try to minimize ineffective measurement 'overspray'. Traceprobe starts by attempting to PING (ICMP ECHO) the actual endpoint target. If the target responds to the ICMP request, then traceprobe will continue to use ICMP to measure that target. If the endpoint target does NOT respond to the ICMP ECHO request, then a traceroute sequence is initiated in attempt to determine a responsive convergence point. Once a convergence point is identified, then measurements to that convergence point are made via ICMP ECHO requests.
Note that if a convergence point stops responding on all links simultaneously, CNA will not interpret that as necessarily a connectivity problem to the actual endpoint. (if an intermediate router reboots, dynamic routing will try to find another path.) Rather, CNA will attempt to identify a new convergence point for the target. If no convergence point can be identified, measurements will cease, and total silence will eventually cause any performance routes to be withdrawn. By default, this process will NOT automatically generate route withdrawal or an outage signal.
Traceprobe default parameters should be appropriate for most production environments. If necessary, traceprobe behavior can be customized with the following commands:
refresh-time proxy-disappeared
For VPN deployments where the end-points are known to be reachable, such as when a central office is probing a branch office, use either TCP or ICMP probes as appropriate for your network policies. For unusual VPN deployments where the end-points are not reachable, use the traceprobe type. For deployments where you have roving VPN users whose addresses are collected through the EFC module and you expect to be able to reach them via the telnet protocol or the ping utility once their tunnels are up, use either tcp or icmp probes.
If you are using the EFC module to obtain addresses of external web surfers and you expect a large percentage of them to be behind firewalls, use the traceprobe type.
If you are optimizing traffic from your local users to external web sites and have manually entered addresses of known web sites, or if you obtain packets through an EFC filter set to listen for traffic going to a remote port 80 destination, use tcp or icmp probes.
Active-measurement groups can now include the optional tos byte <> command. This command allows the ToS byte on outbound measurement traffic to carry the specified ToS value.
active-measurement group tos-marked-measurements type icmp rate 1 per-second efc enable tos byte 16 efc bytes top 5 end
In this example, all outbound measurements for this active-measurement group will include with a ToS byte value of (16).
It is important to understand that the configuration for ToS byte settings encompasses the entire ToS byte. This byte has been defined in a number of different ways over time, with different definitions of the fields within this byte.
RFC 791 and RFC 795, back in September 1981, defined this byte as follows:
Type of Service: 8 bits
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Reliability, 1 = High Reliability.
Bit 6-7: Reserved for Future Use.
Precedence
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine
The three bits at positions (3), (4), and (5) were at this stage collectively known as “ToS bits”.
RFC 1349 (July 1992) proposed an alternate interpretation, which involved expanding the “Type of Service” field from (3) single bit fields, to a single, (4) bit ToS field; but left the “Precedence” bits intact:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+
1000 -- minimize delay
0100 -- maximize throughput
0010 -- maximize reliability
0001 -- minimize monetary cost
0000 -- normal service
RFC 2474 (December 1998) redefines the entire ToS byte into two fields: a (6) bit “DiffServe Code Point” (DSCP), and two bits “unused”:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DiffServe Code Point (DSCP) | Unused |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
CU: currently unused
When configuring the CNA ToS parameter, it is important to remember that in this context, the entire ToS byte is included (values from 0 to 255).
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
For example, the following access list definition:
ip access-list netflow-tos-filter permit tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 tos 16 end
translates to 'only bit [3] is set', which corresponds with ToS “Minimize Delay” setting.
|
|
|