PFRv3 and IP Fragmentation

[julianfletcher]

Can anybody point me to some resources discussing how PFRv3 (as part of an IWAN solution) handles fragmented IP packets (or not) ?

We have an issue with our corporate IWAN solution whereby parent IP fragments are processed by PFRv3  yet child IP fragments seem to be ignored. Thus fragments of an IP packet can travel down different channels (network links) of our network and arrive out of order at a destination. Where destinations are wireless access points (that explicitly don't support out of order traffic) - this causes lots of problems.

[n.oneill]

I don't have an answer but I am curious.

Fragmentation is carried out at the IP layer (Layer 3).  The result is that, apart from the initial fragment, we lose a lot of information.  We know the IP protocol (ICMP, TCP, UDP etc.) but we lose the transport information i.e. the ports the application is communicating on.

I have some questions about your setup:

Is your IWAN policy configured for DSCP values or application id's?

Are the hosts marking the DSCP values or are you relying on inbound marking on the router?

[Joseph W. Doherty]

"Thus fragments of an IP packet can travel down different channels (network links) of our network and arrive out of order at a destination."

Ok, that's possible if IP flow sequence isn't maintained.

"Where destinations are wireless access points (that explicitly don't support out of order traffic) - this causes lots of problems."

The destinations are the WAPs? Not wireless clients using the WAPs?

Fragments are normally reassembled by the final destination host. I didn't think/know a WAP would try to reassemble a wireless client's IP packets.

As to fragments being received out of order, unclear why that would be a problem beyond perhaps impacting the receiving "sequence" of the reconstructed packets. Also are you saying WAPs won't forward the packets and/or fragments as received?

Anyway, as to your original question, I cannot say for sure, but I would expect PfR to only forward IP fragments differently if it's also using L4 headers for its forwarding decisions. For example, treat HTTP like this, but FTP like this; fragments likely not classified as either HTTP or FTP.

If this is the issue, it might be avoided by making forwarding decisions strictly on L3 header info. I.e. Treat DSCP AF21 like this and AF31 like this, etc.