vADC Docs

A guide to Policy Based Routing with Stingray (Linux and VA)

by markbod on ‎03-22-2013 04:55 AM - edited on ‎02-08-2017 06:16 AM by Yousaf.Shah (4,244 Views)

What is Policy Based Routing?

 

Policy Based Routing (PBR) is simply the ability to choose a different routing policy based on various criteria, such as the last hop used, or the local IP address of the connection. As you may have guessed, PBR is only necessary where your Stingray Traffic Manager is multi-homed (ie multiple default routes) and asynchronous routing is either not possible or not desired.

 

There are only really two types of multi homing which we commonly deal with in Stingray deployments. I am going to refer to them as "Multiple ISP", and "Multiple Link".

 

Multiple ISP

 

This is the simpler scenario, and it is seen when a Stingray is deployed in an infrastructure with two or more independent ISPs. The ISPs all provide different network ranges, and Stingray Traffic IP Groups are the end points for the addresses in those ranges. Stingray must chose the default gateway based on the local Traffic IP Address of the connection.

 

Multiple Link

 

This is slightly more complicated because traffic destined for Stingrays Traffic IP can come in via a number of different gateways. Stingray must ensure that return traffic is sent out of the same gateway as it arrived through. This is also known as "Auto-Last-Hop", and is achieved by keeping track of the Layer 2 mac address associated with the connection.

 

 

Setting up Policy Based Routing on Stingray

 

This guide will show you how to set up a process within Stingray Traffic Manager (STM) such that a PBR policy is applied during software start up. The advantage of configuring Stingray this way is that there are no changes to the underlying OS configuration, and as such it is fully compatible with the Virtual Appliance as well as the software (Linux) version. The steps to set up the PBR are as follows...

 

  • Configure gateways.conf for your environment
  • Upload the gateways.conf to Catalogs -> Extra -> Misc
  • Create a new action called "DynamicPBR" in System -> Alerting -> Actions
      1. This should be a program action, and execute the dynamic-pbr.sh script
  • Create a new Event called "Dynamic PBR" in System -> Alerting -> Events
      1. You want to hook the software started event here

 

Step 1: Upload the dynamic-pbr.sh script

 

Navigate to Catalogs -> Extra Files -> Actions Programs and upload the dynamic-pbr.sh script found attached to this article.

 

actionProgs.png

 

Step 2: Configure the gateways.conf for your environment

 

When the dynamic-pbr.sh script is executed it will attempt to load and process a file called gateways.conf from miscellaneous files. You will need to create that configuration file.

 

config.jpeg.jpg

The configuration is a simple text file with a number of fields separated by white space. The first column should be either MAC (to indicate a “Multiple Link” config) or SRC (to indicate “Multiple ISP”).

 

If you are using the MAC method, then you only need to supply the IP address of each of your gateways and their Layer 2 MAC address.


Each MAC line should read “MAC <Gateway IP> <Gateway MAC>”.

 

If you are using the SRC method, then you should include: local source IP (this can be an individual Traffic IP, or a subnet), the Gateway IP. You should also include information on the local network if you need the Stingray to be able to access local machines other than the gateway. Do this using two additional/optional columns: Local subnet and device.

 

Each SRC line should read: “SRC <Local IP> <Gateway IP> <Local subnet> <local device>

 

 

Step 3: upload the gateways.conf

 

Once you have configured the gateways.conf for your environment, you should upload it to Catalogs -> Extra Files -> Miscellaneous


miscFiles.png

 

Step 4: Create Dynamic PBR Action

 

Now we have the script and configuration file uploaded to Stingray, the next steps are to configure the alerting system to execute them at software start up. First we must create a new program action under System -> Alerting -> Manage Actions.

 

addAction.png

Create a new action called “Dynamic PBR” of type Program. In the edit action screen, you should then be able to select dynamic-pbr.sh from the drop down list.

ActionSettings.png

 

 

Step 5: Create Dynamic PBR Event

 

Now that we have an action, we need to create an event which hooks the “software is running” event. Navigate to System -> Alerting -> Manage Event Types and create a new Event Type called “Dynamic PBR”.

 

In the event list select the software running event under General, Information Messages.

 

eventSettings.png

 

Step 6: Link the event to the action

 

Navigate back to the System -> Alerting page and link our new “Dynamic PBR” event type to the “Dynamic PBR” action.

 

AlertMapping.png

 

Finished

 

Now every time the Stingray software is started, the configuration from the gateways.conf will be applied.

 

How do I check the policy?

 

If you want to check what policy has been applied to the OS, you can do so on the command line. Either open the console or SSH into the Stingray Traffic Manager machine. The policy is applied by setting up a rule and matching routing table for each of the lines in the gateways.conf configuration file.You can check the routing policy by using the iproute2 utility.

 

To check the routing rules, run: “ip rule list”.

 

There are three default rules/tables in Linux: rule 0 looks up the “local” table, rule 32766 looks up “main”, and 32767 looks up “default”. The rules are executed in order. The local rule (0) is maintained by the kernel, so you shouldn’t touch it. The main table (look up rule 32766) and default table (look up rule 32767) tables go last. The main table holds the main routing table of your machine and is the one returned by “netstat –rn”. The default table is usually empty. All other rules in the list are custom, and you should see a rule entry for each of the lines in your gateway configuration file.

 

So where are the routes? Well the rules are passed in order and the lookup points to a table. You can have upto 255 tables in linux. The “main” table is actually table 255. To see the routes in the table you would use the “ip route list” command. Executing “ip route list table main” and “ip route list table 254” should return the same routing information.

 

You will note that the rules added by Stingray are referenced by their number only. So to look at one of your tables you would use its number. For example “ip route list table 10”.

ip-rule-list.jpeg.jpg

Enjoy!

 

Updates

  • 20150317: Modified script to parse configuration files which use windows format line endings.
Contributors