cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
596
Views
0
Helpful
4
Replies
Highlighted
Beginner

ACE do not clear the inactive UDP session

Hello

I have an environment in which one host, from the same src ip address and src port, is sending a lot of UDP (Radius) traffic to the VIP:1812.

When the rserver for this VIP does not reply to the particular UDP session (for example, the application on the server is busy for more then 10-12 seconds) the ACE saves such session as inactive in the connection table, but it does not clear it after 2 minutes (default UDP timeout).

During this time the radius probes send to the rservers are being processed without any problems.

Does anybody encounter the same problem ? I would like to know if this behaviour is connected with a bug or I just need to configure some additional feature to fix it.

Thank you in advance for any answers

PS

I am running A2(3.5) version.

Regars

Lukas

Everyone's tags (6)
4 REPLIES 4
Highlighted
Enthusiast

ACE do not clear the inactive UDP session

Hey Lukas,

Do you have any parameter type connection applied?

Is there any other application which reuse Radius traffic or something like that?

Jorge

Highlighted
Beginner

ACE do not clear the inactive UDP session

Hello Jorge

We do not have any parameter_map aplied to this vip. There should be no other app that reuse this connection.

During the problem with this flow, other sources does not have problems with contacting the same vip on port 1812.

Lukas

Highlighted
Enthusiast

ACE do not clear the inactive UDP session

Hi Lukas,

Try to add this command to the class-map inside the policy-map multi-match:

loadbalance vip udp-fast-age

http://www.cisco.com/en/US/customer/docs/interfaces_modules/services_modules/ace/vA5_1_0/command/reference/policy.html#wp1393857

---------------------
Cesar R
ANS Team

--------------------- Cesar R ANS Team
Highlighted
Beginner

ACE do not clear the inactive UDP session

Hello

Thank you. Righ now we implemented an ACL which blocks the UDP packet sourced by the rserver to prevent late radius replies.

It seems to work fine.

Regards

Lukas