The data component executes the following steps to process packets for effective monitoring and mirroring.
The packets being processed are coming from sampled, and are therefore copies.
The code that performs these operations is in the function
process_packet(), in the file
Receive the packet.
If the packet is not UDP, send it out immediately; otherwise, continue.
Look up the flow matching the destination address and destination port in the lookup table (see the note at the end of these steps). When a match is found, proceed to step 5 (FAST PATH); otherwise, proceed to step 4 (SLOW PATH).
In this case, the flow is new, and it is not known whether the flow should be monitored or mirrored. The code looks up the destination address in the configuration stored in the data component.
If the address falls into one of the monitoring groups, the code stores the rate in the flow's state to enable calculating the MDI for the stream the flow is carrying. Similarly, if the flow falls into one of the mirroring groups, the code stores the redirect destination in the flow's state. A flow can be both monitored and mirrored.
The code adds the flow to the lookup table and proceeds.
Given a known flow (match), if the flow is not marked as monitored or mirrored, the application can discard the packet. Additional paths are:
If the flow is marked as monitored, update the MDI state values.
If it is the first packet in the second time frame, and there was a packet in the previous time frame (1 second is used for the MDI delay factor as suggested in RFC 4445; 10 seconds is used for the MDI media loss rate), enqueue an update to be sent to the management component with the previous MDI value for this flow.
If the flow is marked as mirrored, replace the destination address of the packet with the configured destination address, update the necessary checksums, unflag the packet as sampled, and send it out.
If the flow is not marked as mirrored, discard the packet.
Sending and Receiving Status Updates
- An important assumption here is that when dealing with an IP fragment, the application always observes the first fragment first; otherwise, the packets are discarded until the first fragment is received. This is necessary because no port information is present in trailing fragments, so the application cannot determine if the traffic matches that of a known flow. Also, when the first fragment is received, the application must store the fragment ID and match on this in trailing fragments as an alternative to the destination port in step 3.
© 2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5