vADC Forum

Reply
Occasional Contributor
Posts: 6
Registered: ‎07-31-2014
Accepted Solution

Virtual Service Traffic to Gateway .. Directly using TSL

Hi Stingray Traffic Manager genius ...

Is it possible to redirect the traffic directly from :

virtual service1  >>>  gateway1

and

virtual service2  >>>  gateway2

by using Traffic Scripts Language ? no need to pools and nodes in this example ?

Regards

Brocadian
Posts: 230
Registered: ‎11-29-2012

Re: Virtual Service Traffic to Gateway .. Directly using TSL

If you are deploying stingray on Linux as a software installation , you can use policy based routing.  This is something provided as part of your linux distribution.

There is a good article that explains how to set it up here: Configuring Multiple Default Routes in Linux | Darien Kindlund's Blog

Hope this helps.

Cheers.

Aidan.

Occasional Contributor
Posts: 6
Registered: ‎07-31-2014

Re: Virtual Service Traffic to Gateway .. Directly using TSL

Hi Aidan

Yes I know that , but if we use policy based routing , then in this case we don't have the ability to activate the content cache or the the atomizer .. etc.

What I need is a solution to use the traffic manager as default gate way through its virtual services , so you still can use the traffic manager useful features ...

I hope the experiences admins share with us this information

Regards

Brocadian
Posts: 230
Registered: ‎11-29-2012

Re: Virtual Service Traffic to Gateway .. Directly using TSL

I am not sure I follow. Let me clarify with a few elements:

  1. When you communicate from a Virtual Server(VS), the response to the client is sent from the IP address they connected to, so typically the TrafficIP (TIP) the user connected to that is mapped to the VS.
  2. In order to have two applications (lets say ApplicationA and ApplicationB) routed back to the user via different upstream gateways, this can be achieved with policy based routing on Linux. To do this, you would need to have different TIP's for each Application (call them TIPA and TIPB, mapped to ApplicationA and ApplicationB respectively)
  3. You configure your upstream routing such that traffic inbound for the relevant TIPs are routed to the STM via the appropriate upstream gateway (ie: TIPA is routed to the STM via GatewayA, TIPB is routed to the STM via GatewayB)
  4. Your Policy Based Routing (PBR) on each of the STM Linux hosts in your STM cluster would have a rule that says:
    1. Traffic from TIPA (for ApplicationA) routes via GatewayA
    2. Traffic from TIPB (for ApplicationB) routes via GatewayB
  5. With this configuration, you can still leverage all the caching capabilities and features on the STM.

Does this clarify it sufficiently?

--

Aidan.

Occasional Contributor
Posts: 6
Registered: ‎07-31-2014

Re: Virtual Service Traffic to Gateway .. Directly using TSL

Hello Aidan

Just want to thank you for following up my issue , really appreciate it ..

I tried your recommendation but its just not working ...

What I mean by not working is there is no activity on my Virtual Server , it seems the traffic passed directly to the gateway , not through the VS , and all activity diagrams are zeros ...

Only one case I get the traffic passed via VS , its by proxy request (client browser directed to  VS IPSmiley Tongueort) which is not useful for my application .

Ok , I will make it very simple , and if I get this work , then I can solve my problem , as shown in the below diagram :

My network.jpg

I have no problems with the normal application servers ...

My special application server need to connect to the internet via STM eth1 , as its the default gateway for the special application , that it !

Its seems simple but I cannot make it work and keeping STM features as well !

Did I missed something ?

Regards

Brocadian
Posts: 230
Registered: ‎11-29-2012

Re: Virtual Service Traffic to Gateway .. Directly using TSL

ok. I think I see the problem (this probably has more to do with network setup putting the STM on the Traffic path at layer 3), but so I don't make things more complicated, I need to clarify some details so I make sure we get the advice correct for your use case:

  1. Are you using STM installed on Linux or as a Virtual Appliance on a hypervisor?
  2. Do you have one STM, or multiple STM's in a cluster
  3. Is 172.16.30.1 an IP address of a single STM, or a Traffic IP on the inside interface of your STM?
  4. Why is there a router pictured in your diagram between the "Special Application" servers and the STM eth1 interface? By your IP addressing, they are on the same subnet, so a router is not needed between the two, only a switch.

If you can answer these questions, I am confident we can point you in the right direction.

cheers..

Aidan.

Occasional Contributor
Posts: 6
Registered: ‎07-31-2014

Re: Virtual Service Traffic to Gateway .. Directly using TSL

Hi Aidan

Here under my reply to your questions :

  1. Are you using STM installed on Linux or as a Virtual Appliance on a hypervisor?  ESXi 5.1
  2. Do you have one STM, or multiple STM's in a cluster?  One STM
  3. Is 172.16.30.1 an IP address of a single STM, or a Traffic IP on the inside interface of your STM? its IP of single STM
  4. Why is there a router pictured in your diagram between the "Special Application" servers and the STM eth1 interface? By your IP addressing, they are on the same subnet, so a router is not needed between the two, only a switch.  Sorry for that ,its only switch



1st - Waiting your advice on the above .

2nd - more simpler scenario , what if I used a defecated STM for this special application ?

in other words you can ignore the normal application server in the above diagram , what would be your advice ?  

Best Regards

Brocadian
Posts: 230
Registered: ‎11-29-2012

Re: Re: Virtual Service Traffic to Gateway .. Directly using TSL

OK. Here is some pointers:

  1. I strongly advise you think about deploying STM's in a cluster of at least 2 nodes. This will help protect you from outages if the server your STM is hosted on fails. Single points of failure are never fun...
  2. Whether you use one or more STMs, your 172.16.30.1 IP address should be a Traffic IP rather than a real IP of an STM. This will help later if you decide to add another STM to the cluster, as the Traffic IP's can failover between STMs.
  3. For your networking setup, because your servers are already using the STM as their default route, I think all you really need to do is either:
    1. turn on NAT from the STM GUI. This can be found under System > Networking. There are a few differences in how NAT is set up on different versions of STM (STM 9.6 added additional NAT features, so the config is a little different) but it is well covered in the STM User Guide (You can find the latest docs on the SteelApp support page: SteelApp Traffic Manager - the docs are at the bottom of the page); or
    2. If you are running STM > 9.6, you can just turn on IP forwarding under System > Networking

Google Chrome140.png

Hope this helps...

Occasional Contributor
Posts: 6
Registered: ‎07-31-2014

Re: Re: Virtual Service Traffic to Gateway .. Directly using TSL

Thanks Aidan for recommendation 1 and 2 , we shall consider this for sure after checking that every things is Ok .

regarding my problem , I'm using right now the IP Forwarding as mentioned by you in point no. 3 , and my special application is already connected to the internet using this feature ...

But as I said in my first post , its seems the traffic not passing through the virtual server , then non of the useful STM features can be applied ...

For that I'm locking for another way , or the correct way to make the traffic passing via VS  .

Many thanks to you for your support .

Regards

Brocadian
Posts: 230
Registered: ‎11-29-2012

Re: Re: Virtual Service Traffic to Gateway .. Directly using TSL

lioooo,

I can confirm that unless the STM is processing the traffic via a Virtual Server, you will not be able to use STM functions like load balancing, compression, caching etc.

If you are interested, there are iptables configurations that allow you to capture traffic and feed it into a virtual server. This is an 'edge case' for STM though, and can become complex. If you are not familiar with iptables, this might not be the solution for you.

What is the actual problem you are trying to solve?

A.

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.