4 Packet Trace
The SBC's packet trace tool provides the user with the ability to capture traffic from the SBC itself.
WARNING:
packet-trace is purely a troubleshooting tool to be used under guidance by Oracle Support. Oracle recommends using packet-trace only in lab environments not under heavy load.The user invokes the tool from the ACLI, manually specifying:
- How to capture (local vs remote)
- What to capture
- Capture start and stop
There are two capture modes, one that saves traffic locally and one that mirrors traffic to a user-specified target. Software only deployments support local capture only. Proprietary Acme hardware deployments support both local and remote capture.
- Local capture supports PCAP filters to specify the type of traffic to capture. Remote capture supports its own syntax to identify the traffic to mirror.
- Local packet capture is dependent on access control configuration, not capturing any denied traffic. Remote capture mirrors traffic regardless of access control configuration.
- The system does not capture RTP via local packet capture.
- Running packet trace on a standby node is not supported.
Installed NIUs impact remote packet capture. Fragmented packets that ingress HIFNs or Cavium NIUs include only the outer header within the fragments. As a result, these traces do not appear to be using IPIP encapsulation. This differs from fragmented packets that ingress the Quad port GiGE and Copper PHY NIUs. These traces include inner and outer headers within the fragments.
Do not run packet-trace simultaneously with other SBC replication features, such as SRS, SIP Monitoring and Trace, and Call Recording. These features may interfere with each other, corrupting each's results.
The default packet trace filter uses the specified interface to capture both ingress and egress traffic. To specify captured traffic, you can append the command with a PCAP filter enclosed in quotes. PCAP filter syntax is widely published (e.g., via Oracle Linux man pages). The version of libpcap being used can be determined with the show platform components command.
Refer to Wireshark, tcpdump and Berkley Packet Filter (BPF) syntax and example resources as guidance for your capture filters:
https://wiki.wireshark.org/CaptureFilters
https://www.tcpdump.org/manpages/pcap-filter.7.html
http://biot.com/capstats/bpf.html
Note:
When operating on a VNF, The SBC requires that you prepend the VLAN key to a capture filter to run packet-trace on VLAN interface. These commands take the following form.ORACLE# packet-trace local start <network interface> < vlan [vlan_id]&& capture filter>
Examples include:
ORACLE# packet-trace local start M00:100 "vlan && port 5060"or
ORACLE# packet-trace local start M00:100 "vlan 100 && port 5060"Packet Trace Remote
Packet trace remote enables the Oracle Communications Session Border Controller to mirror traffic between two endpoints, or between itself and a specific endpoint to a user-specified target. To accomplish this, the Oracle Communications Session Border Controller replicates the packets sent and received, encapsulates them according to RFC 2003, and sends them to a user-configured target. At the target, the user would capture and analyze the packets. The syntax for remote packet-trace is the same across platforms.
Currently, the Oracle Communications Session Border Controller supports:
- One configurable trace server (on which you capture/analyze the traffic)
- Sixteen concurrent endpoint traces
To use this feature, the user configures a capture-receiver on the Oracle Communications Session Border Controller so that it knows where to send the mirrored packets. Once the capture-receiver is configured, the user issues the packet-trace command to start, stop and specify filters for traces.
You establish a packet trace filter with the following information:
- Network interface—The name of the network interface on the Oracle Communications Session Border Controller from which you want to trace packets. The user can enter this value as a name or as a name and subport identifier value (name:subportid)
- IP address—IP address of the endpoint to or from which the target traffic goes.
- Local port number—Optional parameter; Layer 4 port number on which the Oracle Communications Session Border Controller receives and from which it sends; if no port is specified or if it is set to 0, then all ports will be traced
- Remote port number—Optional parameter; Layer 4 port number to which the Oracle Communications Session Border Controller sends and from which it receives; if no port is specified or if it is set to 0, then all ports will be traced.
The Oracle Communications Session Border Controller then encapsulates the original packets in accordance with RFC 2003 (IP Encapsulation within IP); it adds the requisite headers, and the payload contains the original packet trace with the Layer 2 header removed. Since software protocol analyzers understand RFC 2003, they can easily parse the original traced packets.
It is possible that—for large frames—when the Oracle Communications Session Border Controller performs the steps to comply with RFC 2003 by adding the requisite header, the resulting packet might exceed Ethernet maximum transmission unit (MTU). This could result in packets being dropped by external network devices, but widespread support for jumbo frames should mitigate this possibility.
If the Oracle Communications Session Border Controller either receives or transmits IP fragments during a packet trace, it only traces the first fragment. The first fragment is likely to be a maximum-sized Ethernet frame.
The Oracle Communications Session Border Controller continues to conduct the packet trace and send the replicated information to the trace server until you instruct it to stop. You stop a packet trace with the ACLI packet-trace remote stop command. With this command, you can stop either an individual packet trace or all packet traces that the Oracle Communications Session Border Controller is currently conducting.
Packet Trace Local
Packet Trace Local enables the Oracle Communications Session Border Controller to capture traffic between two endpoints, or between itself and a specific endpoint. To accomplish this, the Oracle Communications Session Border Controller replicates the packets sent and received and saves them to disk in .PCAP format.
The default packet trace filter uses the specified interface to capture both ingress and egress traffic. The command syntax differs based on platform. To specify captured traffic, the user can append the command with a PCAP filter enclosed in quotes. PCAP filter syntax is widely published.
While capturing, the system displays the number of packets it has captured and prevents the user from entering any other ACLI commands from that session. On DPDK systems, you stop captures using the command line syntax with the stop argument. On all other platforms, you terminate the capture by pressing Ctrl+C.
By default, the system saves the .PCAP file in /opt/traces, naming it with the applicable interface name as well as the date and time of the capture. Alternatively, the user can specify file name using the system supports the PCAP filter flags -w.
The system rotates the PCAPs created in this directory by size. The last 25 files are kept and are rotated when they reach 100 MB. If there are capture files in the /opt/traces directory when this command is run, the system prompts the user to remove them before running new captures. If preferred, the user can decline this file deletion.
Local packet capture is dependent on access control configuration, not capturing any denied traffic.
Note:
Although local packet trace captures and re-assembles fragmented packets, it does not recognize and show fragmentation within the context of the capture.Packet Trace Scenarios
This section describes three possible ways that you might use the packet trace feature. You can examine communications sent to and from one endpoint, sent between two endpoints, or sent between ingress and/or egress Oracle Communications Session Border Controller interfaces to endpoints.
Packet Trace for One Endpoint
When you use the packet-trace remote <state> command, the Oracle Communications Session Border Controller sets up packet tracing for one endpoint. The Oracle Communications Session Border Controller collects and replicates the packets to and from one endpoint. To enable this kind of trace, you set up one packet trace using the packet-trace command.
The commands you carry out for packet-trace remote would take the following form:
ORACLE# packet-trace remote start F01:0 <IP address of Endpoint A>
The commands you carry out for packet-trace local on platforms that use the DPDK datapath take the following form:
ORACLE# packet-trace local start F01:0 <"host IP address of Endpoint A">The commands you carry out for packet-trace local on all other platforms take the following form:
ORACLE# packet-trace local F01:0 <"host IP address of Endpoint A">Packet Trace for Both Call Legs
If you want to trace both sides (both call legs), then you must set up individual traces for each endpoint—meaning that you would initiate two packet traces. The results of the trace will give you the communications both call legs for the communication exchanged between the endpoints you specify.
If you initiate a packet trace for both endpoints that captures both signaling and media, the signaling will be captured as usual. However, RTP will only be traced for the ingress call leg. This is because the Oracle Communications Session Border Controller performs NAT on the RTP, which means it cannot be captured on the egress call leg.
The commands you carry out for packet-trace remote would take the following form:
ORACLE# packet-trace remote start F01:0 <IP address of Endpoint A>
ORACLE# packet-trace remote start F02:0 <IP address of Endpoint B>
The commands you carry out for packet-trace local would take the following form:
ORACLE# packet-trace local F01:0 <"host IP address of Endpoint A">
ORACLE# packet-trace local F02:0 <"host IP address of Endpoint B">Packet Trace for a Signaling Address
You can perform a packet trace for addresses internal to the Oracle Communications Session Border Controller; this can be the address, for example, of a SIP interface. Using signaling interface addresses puts the emphasis on the Oracle Communications Session Border Controller rather than on the endpoints by allowing you to view traffic from specified interfaces.
The commands you carry out for packet-trace remote would take the following form:
ORACLE# packet-trace remote start F01:0 <IP address of Oracle Communications Session Border Controller interface1>
ORACLE# packet-trace remote start F02:0 <IP address of Oracle Communications Session Border Controller interface2>
The commands you carry out for packet-trace local on platforms that use the DPDK datapath take the following form:
ORACLE# packet-trace local start F01:0 <"host IP address of Oracle Communications Session Border Controller interface1">
ORACLE# packet-trace local start F02:0 <"host IP address of Oracle Communications Session Border Controller interface2">The commands you carry out for packet-trace local on all other platforms take the following form:
ORACLE# packet-trace local F01:0 <"host IP address of Oracle Communications Session Border Controller interface1">
ORACLE# packet-trace local F02:0 <"host IP address of Oracle Communications Session Border Controller interface2">Note:
The system does not support egress RTP capture with Transcoding NIU