Forum Discussion

Jason_Whiteake1's avatar
Jason_Whiteake1
Icon for Nimbostratus rankNimbostratus
Jan 28, 2015

Broken PMTU Discovery - LTM not returning ICMP Type 3 Code 4

Hello,

 

I have an issue where I can't ping an upstream router interface through f5 LTM. I've created specific IP virtual forwarding servers for inbound and outbound ICMP (IP protocol 1) and applied a FastL4 profile with "Reassemble IP Fragments" checked. I've tried to change the server type to a Performance (Layer 4), but still no luck.

 

I am running LACP on the ingress and egress interfaces. I've monkeyed with the VLAN MTUs. It appears that LTM is black-holing PMTUD. If I ping the upstream interface with a payload size of 1454, the ping's successful. A size of 1455 breaks. TCPDUMP on the inside and outside interface show no attempt to forward an ICMP Destination Unreachable to me, and the packet is never forwarded upstream.

 

I've also monkeyed with the various TMM options:

 

tmsh modify sys db tm.pathmtudiscovery value enable/disable

 

tmsh modify sys db tm.enforcepathmtu value enable/disable

 

tmsh modify sys db route.metrics.mtu value enable/disable

 

As for the route.metrics.mtu, I've tried modifying the individual route MTUs...no luck.

 

Anyone ever see this kind of behavior? I'm wondering if LACP is causing me some sort of issue - why a payload size max of 1454? I should not fragment up to 1472 bytes for payload: 1472 + 8 byte ICMP + 20 byte IP headers. There's an 18 byte difference, as if LTM is taking into account the 14 byte Ethernet header and the 4 byte .1Q tag? We're utilizing Ethernet II/ARPA framing, so there's no 4 byte CRC.

 

Any thoughts/ideas/suggestions would be appreciated!

 

-Jason

 

APM
application delivery
deployment
performance
security
TMOS
TMSH

6 Replies

Sort By
  • Jason_Whiteake1's avatar
    Jason_Whiteake1
    Icon for Nimbostratus rankNimbostratus
    Jan 29, 2015

    Thanks, guys, for the responses.

     

    To answer Q1 - yes, regular packet forwarding is a non-issue. I went through the extra step of creating ICMP virtual forwarders (locked to protocol number 1). I have default IP forwarders that listen for all protocols.

     

    To answer Q2 - I'm running 11.4.1. I reviewed that SOL yesterday, and the odd part is that I actually never receive the Type 3 Code 4s that this bug mentions.

     

    It smacks of a "simple" MTU issue, where payload sizes <= 1454 work. Again, though, all VLAN MTUs are set to 1500.

     

    As I was about to type my next statement about upstream switch interface MTU (they support jumbo frames), I'm now wondering if perhaps this could be an issue. Hmm. Running .1Q over an upstream interface that has an MTU of 9198 bytes. I'd expect TCP to deal with this when it sets up a connection (using its advertised MSS), but I believe ICMP would not be able to fragment if fragmentation was needed. The downstream and upstream user paths are all MTU 1500, and thus why 99.9% of my traffic flows are forwarded without issue.

     

    Let me pursue this angle and I'll post back my findings. I welcome everyone's thoughts as well.

     

  • Jesse_Wahl_3952's avatar
    Jesse_Wahl_3952
    Historic F5 Account
    Feb 19, 2015

    what version? do you have a support case open? it sounds a bit like * [Bug alias 486688 – Improving handling for network and/or wildcard port virtual with multiple HW syncookie learning.]

     

    the workaround for this bug is to disable handware syn cookie protection in the fastl4 profile (and enable software syn cookie protection if desired)

     

  • Jason_Whiteake1's avatar
    Jason_Whiteake1
    Icon for Nimbostratus rankNimbostratus
    Feb 20, 2015

    Hi Jesse,

     

    Thanks for the idea. We've already started our migration, so the problem application has been addressed. I wish I had been able to try this workaround before moving the app, though. :-)

     

    I still have production traffic running through this LTM, so if I see any additional oddities, I'll give this a try. My fastl4 profiles do have hardware SYN cookie protection enabled.

     

    Thanks again!

     

    -Jason

     

  • Jesse_Wahl_3952's avatar
    Jesse_Wahl_3952
    Historic F5 Account
    Feb 20, 2015

    it's important to note that id 486688 only affects hardware platforms which come with an HSB2 asic. cheers! -j