Forum Discussion
NimbostratusPolicy Based Routing (PBR) - Using IP prefix on management and productive interface
Hi,
Guess I have a classic standard problem. I want to serve a service (DNS) in my management network, via a dedicated interface/vlan, not via the management interface. Problem is, that the service interface and management interface have to be able to reach the same IPs/networks. Basically it can happen, that a request on the service interface, would be replied via the management interface. This is what I am looking to solve, f.e. via Policy Based Routing or something similar.
Example:
Management Interface Name: eth0 IP: 192.168.1.10/24 Route: 192.168.0.0/20 via eth0
Service Interface Name: eth3 IP: 192.168.15.20/24 Route: 192.168.0.0/20 via eth3
So basically services listening on eth3 should be able to serve DNS/the service to all nodes in 192.168.0.0/20 but without mixing the interfaces.
Don't know if a Route Domain is what I am looking or if I have to add the interface to the vserver config too or a combination of both or something else.
Any hint and example is much appreciated.
Rgds, SJ
1 Reply
SJ,
If the service traffic is routing through a BIG-IP, then it certainly can be manipulated in many ways. Couple of points of clarity:
EFFECTING TRAFFIC FLOWING THROUGH THE BIG-IP
1) Route domains are a mechanism which allows the BIG-IP to keep separate network name spaces (routing tables and control plane security context) active on a single BIG-IP at the same time. These name spaces can use the same IP (v4 or v6) address space and will keep them separate. They require the use of a decorator for the IP addresses in the form of [IPaddress]%[route domain id]. They don't serve to manipulate traffic while it is passing through the BIG-IP, but simply let the BIG-IP segregate between addresses in different route domains. For most customers, you don't use route domains unless you have overlapping addresses (same IP addresses) which you need to communicate through the BIG-IP. It's the way the BIG-IP keeps the addresses segregated.
2) If you want to force a specific route path through the BIG-IP itself, you can do that in many ways. The most flexible would be the use of a fastL4 virtual service with destination address and port translation turned off (which is routing) and then an applied iRule which can perform programmable logic in the selection of the node to forward traffic.
EFFECTING ROUTING OF TRAFFIC BY EXTERNAL SYSTEMS (nodes)
3) If you want to force external nodes to route traffic back through a BIG-IP, the easiest way to do that is via SNAT (secure network address translation) which rewrites the source IP address to an address which belongs to the BIG-IP (SNAT translation address). The node would see the traffic as originating on the BIG-IP and would return traffic to it. SNATs overcome routing problems. The BIG-IP, which is statefully translating traffic based on L4 source port manipulation, would handle the translation of the IP address back to the originating client.
It appears from your comment that you are using a linux based system. You don't need BIG-IPs to handle interface based policy routing for linux hosts. You can use the ip command (man ip) to create route rules which can include the ingress interfaces. Note: on the control plane (route table) this is how your BIG-IP has multiple default routes, one for traffic originating through the management interface, and another for traffic flowing through TMM data planes. You can do that on your own servers too.
You use BIG-IPs to manipulate traffic (L3-L7) flowing through it if you did not want to, or could not, provisions the servers (nodes to BIG-IPs) to understand the traffic flows. The BIG-IP is a swiss army knife for network flows, but at times, good old fashion route intelligence on the server can do the trick.
Hope this helps.
John
