If it is low cost to have dropped events, then you can just ignore it (?).
As a simple implementation, you could have the output disruptor on the primary notify the slave that it has completed sending a packet. Think of it as a two-stage replicator - one to replicate the event, and a second replicator to confirm that the event has been sent.
In a real world implementation you may need additional downstream support in your architecture (especially replay / retry). Depending on your application requirements, you need a capability to detect that there is a gap in the output events and fetch them as necessary. Assuming your events are idempotent, there should be no issues to go back in time and replay the events.
Suppose a single packet is lost on your outbound channel or your internet line goes down? Even if it is successfully sent out from the disruptor, it can still be lost. This depends on your specific application and requires a lot more thought than can go here as to what failure scenarios you can tolerate.