Dropped Radius Packets with 80.20 Gateway

[dj0Nz]

Hello,

just upgraded a CPAP-13500 cluster to R80.20. Everything worked fine except that RADIUS packets (1812/udp) larger than about 1000 bytes getting dropped without log, not even with a drop debug message. Seems like they get dropped at the interface level, somewhere between interface and In-Chain.

If I tcpdump on incoming and outgoing interface, I can see packets incoming to the gateway but none is leaving on the outgoing interface. If I'm using fw monitor, I even can't see any packets.

Reverting to R77.30 solved the problem.

Does anybody have a clue? Is this a known issue? 

Bye
Michael

[dj0Nz]

Problem solved. Almost. 

Maybe (!) sometimes it's better to have a look at the log. There, I found dropped packets, drop reason "Virtual defragmentation timeout" ("UDP/0 Traffic Dropped from x.x.x.x to y.y.y.y").

Interesting in that case: only a very specific type of traffic is triggering this issue: RADIUS packets with MF Bit set.

To me, it seems like the R77.30 gateway simply forwards these packets, even if no more fragments arrive. I can see these packets on both incoming and outgoing interface.

The R80.20 gateway drops the first fragment if no other fragment is following, which should be normal behaviour according to sk97666.

[Vladimir]

I think I'e run into a similar problem recently and CP R&D has helped to remedy the issue.

The problem was broader than just RADIUS. Latest report from the client indicates that "newest R80.20 take 47 and two post-jumbo hotfixes addressing the fragment minimum size in fw and coreXL."

The issue was encountered on 13000 series VSX cluster VS after upgrade to R80.20.

[Timothy_Hall]

The fact that this this issue with handling fragments occurs on an R80.20 gateway makes sense, since handling of IP fragments was significantly changed starting in this release with the reworking of SecureXL.  Receipt of fragmented packets no longer dooms them to non-acceleration in the F2F path as it did in R80.10 and earlier, since SecureXL is now capable of performing virtual reassembly itself in R80.20+.  This is most definitely a positive development but corner-case frag issues like these may certainly crop up due to the changes, glad to see they were patched quickly.

[dj0Nz]

In case someone runs into the same problem: It finally turns out this is an issue with the Cisco WLC devices the customer uses: The authentication packet they send is about 1650 bytes, but only the first part (about 1420 bytes) is seen on the wire with MF bit set. The rest of the packet never leaves the WLC device. Nevertheless, authentication works - with a R77.30 gateway between WLC and RADIUS... 

[Tommy_Kim]

I have simillar experience in R77.30 gateway. and It turn out Cisco switch bug.

So I'm share with Cisco site, refer to it.

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvk53444

[dj0Nz · Accepted solution]

Just in case, anyone has a similar setup: We finally solved the problem by configuring IPSEC between WLC devices and RADIUS server (Cisco ISE).