Redirecting part of a URL

[SteveD1979]

Hi,

I'm trying to redirect part of the URL but not the whole URL.  The URL would be hitting our GTMs first and be something like application.something.gtm.domain.com and I want to flip it to something like application.something.datacenter.domain.com on the BIG IPs.

[SteveD1979]

I forgot to mention that the pool is going to be our openshift router so several applications will be hitting it.  We'll have separate WIPs for each app on our GTMs but the pool would be the same on the LTMs so the irule on the LTM i'd like to have any application.something coming in be able to switch the gtm.domain.com to the datacenter.domain.com keeping everything in front of it.  Our openshift engineer doesn't want to have to add the .gtm.domain.com route to each application.

[Paulius]

@SteveD1979 First I will be changing domain.com to example.com. I'm not understanding why the client would be entering application.something.gtm.example.com in the first place. Typically the way DNS is configured is you would have the following.

*** DNS at auth NS for example.com ***
application.something.datacenter.example.com  300  IN  CNAME application.something.gtm.example.com

*** DNS on GTM for gtm record ***
application.something.gtm.example.com  300  IN  A  1.1.1.1
application.something.gtm.example.com  300  IN  A  1.1.1.2

Then the client would connect to either IP depending on what the GTM responded with while still maintaining the FQDN application.something.datacenter.example.com. Typically you wouldn't want to narrow down the FQDNs to be a specific datacenter name because that allows people to aquire more information about your infrastructure than they should.

[SteveD1979]

Right that's how everything else we have is setup.  For this situation though right now they're just using LTMs in separate datacenters.  There is an A record that points to a VIP in the datacenter that is active and for a disaster recovery situation DNS would be changed to point the record to the VIP in the other datacenter.  The DNS records are wildcarded *.datacenter.domain.com to 1.1.1.1 and that resolved to a VIP with the openshift routers as the pool members.  Based on the application.something part of the URL Openshift knows where to route the traffic.  

For this they want the developers to have a singular URL for their apps that wouldn't have to be changed in a true disaster or just a disaster recovery exercise so that would be their application.gtm.domain.com.  There would be a separate WIP for each.  So in a disaster situation we would just disable the pool member on the GTM for the datacenter that they weren't running out of.  

The openshift configuration needs to have a route configured to know which application is being called.  Right now thats the application.something.datacenter.domain.com and those engineers don't want to have to add another route (the gtm.domain.com) for each application.  This is all internal traffic not exposed to the internet.

It isn't going to be a hot/hot scenerio but we wanted the developers to have one URL, traffic to know which datacenter based on the pool member enabled on the wide IP but then when it gets to the VIP on the LTM change the URL ending so that openshift still see the route and knows where to send the traffic.

When we do disaster recovery exercises not all of the applications do it at the same time so we need to be able to send some traffic to one datacenter or the other.

[Paulius]

@SteveD1979 The following is what you should have for each application.

*** DNS Auth for example.com ***
application.example.com

*** DNS on GTM ***
application.gtm.example.com

Having the above configuration for each application will provide you the flexibility of being able to failover each application without much complexity on the GTM side of things. I believe it is possible to create a data-group with every application and a value of 0 or 1 and then configure an iRule to reference the data-group to check each application and it's value and failover based on that but that adds unneaded complexity to the GTM configuration.

[SteveD1979]

That's how we have every other application configured that have their own dedicated static VIPs on the LTMs.  For this since there are so many applications hitting the same VIP and not all can be moved I thought it would be easier if i could just redirect part of the URL.  I'm not sure how to do that with the datagroups but are you saying redirecting part of a URL isn't possible?  I tried a policy and several irules to look for contains and replace in the URL but it wasn't working.

[Paulius]

@SteveD1979 The issue here is that you have 2 different pieces handling two different parts of your request.

1. The GTM will resolve all DNS requests it is sent.
2. After you have DNS resolve you then have your request directly to the destination IP that the GTM pointed you to for lets say application1.example.com. This part of the request is not something the GTM would see because it is an application request and not a DNS request. The GTM doesn't change the original FQDN that you are attempting to resolve a destination for.

[SteveD1979]

Right i wanted to put an irule or policy on the VIP on the LTMs to redirect it from the gtm.domain.com name to the datacenter.domain.com name that it's expecting but keep the part of the URL that is wildcarded so that openshift would know where to send it.

DNS record currently *.datacenter.domain.com = VIP on LTM for openshift router with several applications hitting it.

DNS record desired for developers to use = theirapplication.gtm.domain.com

Route currently openshift is configured to recognize = theirapplication.datacenter.domain.com

[Paulius]

@SteveD1979 Your developers should not be using the FQDN of theirapplication.gtm.example.com they should be using theirapplication.example.com. Please take a moment to look at the two images that explains a little on what is happening when the developers make a query for their app and how DNS should be configured so that the GTM is used appropriately to minimize what the client sees. Pay close attention to what comes back in DNS and what the client uses to make the application request.

 

 

[SteveD1979]

I understand that but it would still be the same scenerio.  I just wanted to see if it would be possible to rewrite a portion of the URL.  If not I'm going to have get our openshift engineer to just add this route.  Nothing was settled on yet the URL the devs use could be just application.domain.com but i would still need to flip it to what openshift is expecting as the route

[Paulius]

@SteveD1979 In order to understand this a bit better could you go into a bit more detailed explanation of Openshift? From what I can tell Openshift has a list of applications and their respective FQDN match. So in this list if they the following I am still failing to see the issue.

theirapp1 -> theirapp2.example.com
theirapp2 -> theirapp2.example.com
theirapp3 -> theirapp3.example.com

If you have to hardcode the destination IP for each app then I can see why you might have an issue but other than that I'm not sure why this is an issue. If I'm incorrect in my assumption please provide some additional detail on how openshift application references function.

[SteveD1979]

The DNS record and the cert for the openshift URL are both wildcarded.  so anything that has the *.datacenter.example.com is going to hit the VIP that has the openshift routers behind it.  Once it hits the openshift router it sends the traffic to the correct app depending on what is before the .datacenter.example.com in the URL.  It's a separate wildcarded DNS based on the datacenter.  Openshift is only set up to accept traffic from the routes configured.  We're trying to get away from using the specific datacenter in the developers code but also trying not to have to configure a new route inside of openshift.

theirapp1.datacenter.example.com -->  resolved to openshift router VIP expecting *.datacenter.example.com --> routes to correct openshift container based on theirapp1

Openshift has to see the .datacenter.example.com to allow the traffic.  And all of the applications hit this same VIP.

desired

devs hit GTM theirapp.example.com --> traffic forwarded to appropriate LTM pair in active datacenter that *.datacenter.example.com resolves to --> LTM irule flips theirapp.example.com to theirapp.datacenter.example.com --> traffic goes through to pool member with new URL and openshift expects this host route.

[SteveD1979]

Also obviously i could do this for each individual app but there are many.  I wanted to see if there was a way where i could take any request coming in that was in theirapp.example.com and flip it to theirapp.datacenter.example.com 

[Paulius]

@SteveD1979 Do you intend for this to be a redirect or a rewrite that only the pool member sees? Is the "theirapp" always the same length and in the 3rd section of the FQDN?

[SteveD1979]

I think either would work and it would always be whatever comes before the example.com but different legnths 

[Paulius]

@SteveD1979 If you will always convert .gtm. to .datacenter. you can do the following.

when HTTP_REQUEST priority 500 {

    if {[HTTP::host] contains ".gtm."} {
        HTTP::host [string map {".gtm." ".datacenter."}[HTTP::host]]
    }

}

[SteveD1979]

Thanks I tried that but it isn't flipping it.

[SteveD1979]

Does it matter that this is a performance layer 4 VIP?

[Paulius]

@SteveD1979 If this is HTTP traffic you can change it to a standard, apply an HTTP profile, and the irule in question and it should work. If you are doing HTTPS communication it would require that you change it to standard, HTTP profile, SSL client profile, and the iRule and it should work.

[SteveD1979]

Ok thanks.  Per openshift the VIP has to be layer 4 but i was able to put the HTTP profile on it since the one we're testing is http and since it let me add the irule with http_request i thought it might be ok.

[Paulius]

@SteveD1979 Sadly, with an SSL connection and you do not have SSL termination being performed on a standard VS you cannot have an HTTP profile because the F5 cannot look at the HTTP header since it's encrypted.

[T-Trust]

Hi SteveD1979,

Do you want reditect level GTM or LTM ?

[SteveD1979]

Either one should be fine but I might need to do it differently if it isn't going to work with the http protocol profile on the VIP.  I thought since it let me apply it and update and also with the when http_request irule without throwing errors that I'd be able to use them.  I wanted to use the x-forwarder too