Jump to content
Welcome to our new Citrix community!

CS Vserver Policies vs Responder Policies...


Recommended Posts

Disclaimer: This might be a dumb question :) 

 

I am curious specific to the behavior of CS vServer policies and responder polcies and wondering if someone can help set my mind straight on how the NS handles things from the CS Vserver perspective. Let's say I have 3 policies setup on a CS vServer to filter on URL's... 

 

http.req.url.path.get(1).eq("test1")

http.req.url.path.get(1).eq("test2")

http.req.url.path.get(1).eq("test3")

 

There is no default vserver bound to this cs vserver... 

 

If a request comes in that has the URL path "test4" will the Netscaler inherently drop the request if there is no policy to match on? 

 

I was about to make some changes to a cs vserver we have in production. Currently it is setup with only a default vserver (no URL matching policies were previously needed). Now we need to filter on URL. I was going to setup both cs policies and also a responder policy to drop anything that is not in the policy list... but if the NS inherently will drop anything it does not match on, I should theoretically not need the responder policies. Is my thinking correct? 

 

Thanks in advance for anyone who can chime in on this.  

Link to comment
Share on other sites

If a request comes into a CS vserver with no destination, then you the request is terminated, but not exactly dropped.  What the user will see in the browser (if web based) is a "service unavailable" message - which can't be modified in this context. The request is terminated, but there is something for the user to see, that might generate more support calls than the drop behavior.

 

A responder policy can drop/reset or redirect to an error page or status message like "content not available". And this might be preferred behavior.

 

So, I think always having a plan for unhandled content is better than letting it go nowhere. It won't pass the traffic, but its better to do something with it in this case.

 

In this case, assigning a default destination that sends to a non-addressable vserver is still preferred, you could then bind a responder policy here which drops or redirects traffic.

this gives you flexibility down the road as 1) you can handle different traffic different ways if needed.

 

 

 

  • Like 2
Link to comment
Share on other sites

15 minutes ago, Rhonda Rowland1709152125 said:

If a request comes into a CS vserver with no destination, then you the request is terminated, but not exactly dropped.  What the user will see in the browser (if web based) is a "service unavailable" message - which can't be modified in this context. The request is terminated, but there is something for the user to see, that might generate more support calls than the drop behavior.

 

A responder policy can drop/reset or redirect to an error page or status message like "content not available". And this might be preferred behavior.

 

So, I think always having a plan for unhandled content is better than letting it go nowhere. It won't pass the traffic, but its better to do something with it in this case.

 

In this case, assigning a default destination that sends to a non-addressable vserver is still preferred, you could then bind a responder policy here which drops or redirects traffic.

this gives you flexibility down the road as 1) you can handle different traffic different ways if needed.

 

 

 

Thanks for this, as always. I agree 100%  

Link to comment
Share on other sites

1 hour ago, Todd Harrington said:

Disclaimer: This might be a dumb question :) 

 

No such thing, Todd! :27_sunglasses: 

 

Based on my understanding, Content Switching can only be used to direct requests to LB vServers based on expression matches like you have above and cannot be configured to drop/reset requests based on expression matches.

 

I think that, in addition to the three CS Policies you have configured and bound on the CS vServer to direct traffic to the specific LB vServers, you could configure a Filter Policy with an expression to look for 'test4' and configure the action to drop or reset that request.

 

The Policy Engine will process Responder Policies before Filter Policies and Filter Policies before CS Policies, so any requests matching a Responder Policy or Filter Policy would be acted upon before hitting the CS policies. 

 

I believe with Responder, you can only respond to the request with a redirect or with or with a particular type of error, whereas with Filter Policies you are given the option to drop or reset requests. 

 

Responder Actions:

image.png.31bae376446bd954f3901dfba73c5649.png

 

Filter Actions:

 

image.thumb.png.f274b5f53af778ce46665fb38dd9a6a3.png

  • Like 1
Link to comment
Share on other sites

Thank you Jim for the input. You bring up an interesting point on the policy engine. I did not realize that responder polices get processed before cs policies. This is a really helpful piece of information. Rhonda's suggestion is probably a good practice to get into for me as we have been using content switching more and more lately. Let the CS vserver handle the cs policies and then send the traffic to a non addressable vserver for any requests that do not match and then let that policy/filter handle any "non relevant" traffic. 

 

I have not messed around with the filter policies at all yet, I have been able to do almost everything I have needed to do with responder... do you know how the filter policies differ from responder, seems like you can accomplish the same with both? Is responder just a little more robust? 

 

Thanks again

Link to comment
Share on other sites

Well, what I didn't realize is that under the Responder Policy you can configure the DROP or RESET action in place of a Responder Policy.  My apologies for the confusion there.

 

Filter Policies are just another way to filter traffic, which can help optimize performance by not allowing traffic containing any content defined by the policies to be processed further once detected.  It appears though, they are limited to DROP and RESET and Responder can do those in addition to taking additional action.

 

I would say if anything they can be considered complimentary to other policies, especially in environments handling large volumes of traffic.

Link to comment
Share on other sites

Thanks again Jim, the info was helpful! :) 

 

I was searching a little more on how the policy engine processes requests and the order in which they are processed... did not find a ton from Citrix directly that was definitive but I did come across this article from eBay. Apparently they use ADC and did some tests to understand this a little better. Kind of cool real world testing. Might be useful information for someone else looking for this information as well so linking here: 

 

https://www.ebayinc.com/stories/blogs/tech/optimization-study-on-processing-order-of-netscaler-load-balancer-layer-7-policies/

Link to comment
Share on other sites

Content switching is technically evaluated before responder, but traffic is not sent content switched to destination until later in flow - so a responder policy will drop it, if you follow the packet processing flow diagrams from citrix. You still want unexpected traffic going somewhere, so the default destination can be combined with the responder policy to handle traffic. The responder policy can be applied at either the cs or lb level, but it would be more efficient in this case on the default destination, since he's trying to filter the traffic not matched to an existing cs policy.  Here's the processing flow diagram for citrix bottom half of this section:  https://docs.citrix.com/en-us/netscaler/12/getting-started-with-netscaler.html

But responder policy on the cs vserver or the other method proposed will both work; there is more than one way to accomplish the intended result. :)

 

Jim - keep in mind content filtering is a classic engine feature that gets deprecated and goes away with the removal of the classic engine, because it is replaced by responder (and other features). But yes as you noted: responder can drop/reset/redirect or can do a custom response for traffic) so it is your universal content filter in the advanced engine.  But responder also processes much earlier in the flow than content filtering (and most other features).

 

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...