cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
27425
Views
6
Helpful
7
Replies

Radius Framed-MTU attribute

We are trying to solidify our 802.1x configurations on ACS pending a migration to ISE.  We have a Cisco 3750x running 15.2-4E5, talking to a Cisco Access Control Server 5.2 over a WAN that can carry UDP at 1256 bytes.  Anything greater is dropped.  EAP-TLS is failing because the switch is sending packets that are too large (verified by captures).

Question surrounds Radius-IETF attribute 12 (Framed-MTU).  There is much documentation out there how to fix Microsoft NPS and even FreeRadius.  Is there a simple way to fix this problem from either the Authenticator (3750x) or the Authentication Server (Cisco ACS) perspective?

We have already included attribute 12 in all authorization profiles on ACS, and set static to value 1200.  However all "access-challenge" packets from ACS do not have the attribute included (again verified by captures).  We have also verified the switch is not honoring the "system mtu" (currently 1500) and even firing packets at greater than that.  Any assistance would be sincerely appreciated. 

1 Accepted Solution

Accepted Solutions

ccaporal
Cisco Employee
Cisco Employee

Michael,

The TL;DR solution is set your Framed-MTU to 1002.

It sounds like you're hitting something I struggled with a few years back myself, as soon as I started to do an EAP-TLS auth and realized the EAP packets needed to be fragmented.   You hit on the right solution, adding the Framed-MTU attribute to the Authorization Profile.  I would probably consider 1002 as a more appropriate value (standard in the current versions of ISE).

EAP itself cannot tolerate fragmentation and must receive the complete message intact, but certain EAP methods have a way of dealing with frags.  Within the context of EAP, the Framed-MTU doesn't control the MTU of the outer packet that gets fired down the WAN, it controls the EAP maximum message size.  If the EAP-TLS message is larger than the Framed-MTU, then the message is broken up locally, and a "fragmentation" flag is added to each message.  Before the NAD will send subsequent fragments to the RADIUS server (or vice versa), the previous one needs to be ACK'ed, and the fragmentation flag tells the other side this needs to be done.

I wouldn't necessarily get too concerned about the switch sending other types of data with frames larger than the 1256b, that would be expected for traffic within the remote site, and outbound fragmentation would be handled by the ASA or ISR acting as the VPN. 

View solution in original post

7 Replies 7

Jason Kunst
Cisco Employee
Cisco Employee

This appears to be a switching issue did you ask that team?

Not saying there's any issues switching or ACS.  More of a generic how/guidance question. 

Need radius UDP packets to be < 1256 for 802.1x.  How?

hslai
Cisco Employee
Cisco Employee

RADIUS Attribute Framed-MTU might help.

CSCup19873 is an existing enhancement request.

Leaping to an assumption, if that's a feature request for ISE, then I would surmise that I'm not going to be able to get ACS 5.7 (typo above) to return a standard IETF attribute (12) to an authenticator like it seems most other radius servers can do via initial access-challenge.

Back to authenticator end, we've tried tricking it any way we know how.  System/jumbo/routing MTU less than 1500 not supported in any way.  Although set to 1500 across the board it's firing 1800-byte-plus packets.  We've tried forcibly setting the df-bit to get the switch to respond to ICMP unreachable (Fragmentation needed) but those are ignored.  If I let the already-fragmented UDP fragment again (instead of drop) the ACS server returns TTL-exceeded (fragment reassembly time exceeded) ICMP messages.

Very much open to any lessons-learned or potential fixes here.  I asked if there was an "easy" way now I'm wondering if there's a hard way, or a way at all.

ACS 5.7 has reached End of SW Maintenance Releases Date: App. SW

ACS 5.8 in another year. Thus, it's unlikely to address it in ACS.

As discussed internally, CSCvf52213 has a workaround that TAC may apply to an ISE system. This may or may not work on ACS.

ccaporal
Cisco Employee
Cisco Employee

Michael,

The TL;DR solution is set your Framed-MTU to 1002.

It sounds like you're hitting something I struggled with a few years back myself, as soon as I started to do an EAP-TLS auth and realized the EAP packets needed to be fragmented.   You hit on the right solution, adding the Framed-MTU attribute to the Authorization Profile.  I would probably consider 1002 as a more appropriate value (standard in the current versions of ISE).

EAP itself cannot tolerate fragmentation and must receive the complete message intact, but certain EAP methods have a way of dealing with frags.  Within the context of EAP, the Framed-MTU doesn't control the MTU of the outer packet that gets fired down the WAN, it controls the EAP maximum message size.  If the EAP-TLS message is larger than the Framed-MTU, then the message is broken up locally, and a "fragmentation" flag is added to each message.  Before the NAD will send subsequent fragments to the RADIUS server (or vice versa), the previous one needs to be ACK'ed, and the fragmentation flag tells the other side this needs to be done.

I wouldn't necessarily get too concerned about the switch sending other types of data with frames larger than the 1256b, that would be expected for traffic within the remote site, and outbound fragmentation would be handled by the ASA or ISR acting as the VPN. 

How does one go about this in Cisco ISE?  You can do this in the Authorization Profile but not the Authentication... I see no place to apply Framed-MTU in the Authentication process.  Identity Sequence, Allowed protocols, etc...