Session Mirroring Overview
This topic describes session mirroring for the BGF voice solution.
Session Mirroring Introduction
Session mirroring allows you to send a copy of a context to an external device called a delivery function for analysis. With session mirroring, the original session is sent to its intended destination and the mirrored session is sent to the delivery function. The mirroring operations are transparent to the user whose session is being mirrored.
Session mirroring is supported for IPv4 and IPv6 traffic. IPv6 packets that are mirrored are encapsulated in IPv4 headers.
The BGF can mirror up to 1 percent of gates at a time.
Activation of Session Mirroring for a Gate
When session mirroring is enabled, the BGF uses information in H.248 requests received from the gateway controller to identify sessions to be mirrored and to trigger the mirroring session. The following sample H.248 request includes session-mirroring information:
MEGACO/2 [123.123.123.3]:2944
Transaction = 10003 {
Context = $ {
Add = $ {
Media {
LocalControl {
Mode = SendReceive,
li/LICn=ff00ff00ff00ff00},
li/LITID = [ffffff00, ffffff01],
Remote {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 0
a=ptime:20
}
}
}
}
}
- The LICn command provides an encrypted correlation number. The pgcpd process decrypts the correlation number to determine whether session mirroring is performed on the gate. If the number is valid, interception is performed on the gate. If the number is invalid, no interception is performed on the gate.
- The LITID command contains one or more target IDs that identify the recipients of mirrored packets. If the request contains multiple LITIDs, a copy of mirrored packets is created for each target ID. All copies are sent to the same delivery function. A maximum number of seven copies is supported for each packet.
How Session Mirroring Works
If session mirroring is required on a gate, the pgcpd process embeds appropriate data in the gate open/modify request that it sends to the PIC or DPC. This data includes direction information to indicate whether the packet is mirrored before applying NAT actions or after. It also includes the decrypted correlation number and Target IDs that need to be embedded in the packet sent to the delivery function.
The PIC or DPC then:
- Marks the gate that needs to be mirrored and obtains the destination for the mirrored packets from the CLI configuration.
- Processes the packets as it normally does. It applies
DSCP, latching, and rate limiting as appropriate.
- Additional mirrored packets that are sent as a result of session mirroring do not impact rate limiting. The replicated packets do not count against policer counters that are used to compute the rate for the gate.
- Mirrored packets are sent with DSCP marks that are applied to the gate as they are for a normal flow.
- If the original packet is dropped because of rate limiting; no mirroring occurs.
- Latch or relatch actions on the gate do not impact mirroring.
- Generates one copy of the packets received on mirrored gates for each target ID specified in the H.248 request, encapsulates the mirrored packets, and sends them to the configured delivery function.
Session mirroring can be enabled or disabled any time during a gate’s life by employing H.248 commands. If mirroring is enabled in one stream of a termination, all streams in the context are mirrored. Both RTP and RTCP packets are mirrored for a gate marked for mirroring.
Protecting Mirrored Sessions with IPsec Overview
You can use IPsec authentication and encryption to protect session mirroring call content (that is, the X3 interface). IPsec tunnel mode is supported for mirrored sessions.
