Egress Sflow of Jumbo Frames

[Michael (Mike) Fink]

Hello,
Question about jumbo frame sampling on egress. When a jumbo frame is received, it will be sent to CPU, and then fragmented to send out multiple frames. If egress sFlow is enabled on the ports sending out the fragmented frames, is the correct source port to use in the flow sample the interface where the jumbo frame was received, or internal interface, 0x3FFFFFFF, since these fragmented packets are technically coming from CPU?

I lean towards the source port being the correct option, but wanted to get some feedback.

Thanks,

Mike

[Peter Phaal]

On Wednesday, May 20, 2020 at 2:02:53 PM UTC-7, Michael (Mike) Fink wrote:

Question about jumbo frame sampling on egress. When a jumbo frame is received, it will be sent to CPU, and then fragmented to send out multiple frames. If egress sFlow is enabled on the ports sending out the fragmented frames, is the correct source port to use in the flow sample the interface where the jumbo frame was received, or internal interface, 0x3FFFFFFF, since these fragmented packets are technically coming from CPU?

I lean towards the source port being the correct option, but wanted to get some feedback.

Your instincts are correct. The internal interface is intended for control plane traffic terminating or originating on the switch (e.g. LLDP, BGP, OSPF, etc.). The sFlow data model recognizes that packets may be transformed as they pass through the switch and allows information describing the transformation to be attached to the sampled packet header in the form of extended flow records (e.g. tunnel encapsulation / decapsulation, address translation, etc.). Fragmentation is one of these transformations and doesn't change the ingress port information.

It is essential that the data source information is correct. For the fragmented packets sampled on egress, the data source is the egress port and the reported packet header must reflect the bits sent on the wire. The jumbo frame sampled on ingress would have the ingress port as the data source.

[Michael (Mike) Fink]

Thanks Peter, that's helpful.

Just to be completely clear, let me set out an example:

A packet ingresses intf 1 and is destined for intf 2.

The packet is fragmented into multiple frames, each of which egresses intf 2.

Egress sflow is enabled on intf 2 and the data source for each sample is intf 2.

The output interface for each sample is also intf 2.

The input interface for each sample is intf 1, despite the fragments originating from CPU.

Is that accurate?

Cheers,

Mike

[Peter Phaal]

You have it correct. 

Out of curiosity, it surprises me to hear that fragmentation in a switch is performed in software. I would have thought the ASIC would handle fragmentation? Definitely worth getting the MTUs right to avoid fragmentation.

--
You received this message because you are subscribed to the Google Groups "sFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sflow+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sflow/7d93dfc2-93bb-42f9-a429-6ce360e95f9a%40googlegroups.com.