CSS behaviour when client request not match any content rule

[joey-lin]

Dear all,

I'd like to know the CSS default behaviour when a TCP request does not match any content rule. Will CSS send back TCP RST to client, ignoring the request with no any reponse, or other action?

My scenario is configuring all services and content rules with tcp/udp port number(Layer4-LB). Assume I configured content rules to match tcp port 100, 200, 300, 400, and intend to achieve that all client TCP SYC request to receive TCP RST response, except for those TCP SYN request destinated to above ports (which should be balanced to real servers). Can this be done?

[d.parks]

I believe the CSS will simply ignore the request. I say this because I've taken traces where traffic actually matches a rule, but no service is availiable. The CSS seems to ignore the request even in this scenario.

There is a flow-reset-reject command for content rules, but I beleive this only sends a reset for already-established connections that need to be torn down when a service goes down.

[joey-lin]

Thanks a lot for the information you provide.

For those who are interested in this topic, FYR, you can also check the related post, including "what happens if the service is down" on Mar 23, It seems Gilles have done a test on flow-reset-reject command ; and "CSS - Content Rules with no available services" on Nov 20.

My questions including the following,

1. I can't find any material on CCO that completely describe the flow process. All I see is "When a request for content is made, ..." I can't see much reason to not to include related information on CSS technical document.

2. The flow-reset-reject command is not described clearly enough in related document. If Gilles does't do a test, who will know this command applies to L5 content rule only? (I haven't made such verification by myself)

3. Assume the behaviour is as your description, (sorry I also haven't made such verification by myself until now), obviously it doen't comply with RFC 793. I believe this can be part of DoS (TCP SYC)protection mechanism. Again. no description about related topics. I'm not sure if all L4 devices have such issue/feature. Do we have any option to avoid it? In previous DoS related discussion, it seems we don't have a choice. Anyone know other vendors' behaviour?

4. The workaround I can think now, is creating a service and content rule with L3, which the VIP is the same with those L4 services and rules. Since all request will use the longest match first, for those request matches the port I defined, they'll be served correctly. For those request doesn't match the ports I defined in rules, their destination IP will match the L3 rule. In the L3 rule, define the sorry server, using the sorry server to reply the requester with TCP RST.(similiar to thomsoa using in Nov 20 post. But as he said, convince the customer is always a big trouble. Especially if any other L4 devices have control options on this topic) I haven't test it yet, any opinion is welcome.

5. Why the customer have such request that L4 devices sould comply with RFC 793 is because, in mobile environment, the air time is still expensive. Once the end-user can't get reply instantly, there will be a long waiting time before the retry counters and timers expired. And these air time are still in charge if the end-user's billing package is not charged by content.

[Gilles Dufour]

I think your request to have the CSS reply with a RST when no VIP is hit is valid.

I will check with developpers what they think about it and will submit a feature request.

Gilles.

[peucale]

Hi,

I think that the CSS won't intercept a packet when there is no content rule match. BTW, why should the CSS answer for a request that it does not have a content rule for? The CSS routes all traffic that does not match any content rule.

Another thing is if a content rule does not have any active services anymore. Then the CSS just hides it. So, if you try to reach the content rule you will not get an answer. This is not that good, but you can configure a sorry-server for that case.

On the other hand, a good solution would be to sent a Port Unreachable as well.

- alex

[andrew.thomson]

I see you are having similar problems to me. Have you considered having a "catch-all" rule that will:

- match all remaining requests after failing match on all content rules,

- making it a sticky rule,

- having a single backend server that is never available and

- using "sticky-serverdown-failover reject"?

Good luck....