Forum Discussion

atoth's avatar
atoth
Icon for Cirrus rankCirrus
May 11, 2013

Doing redirects from VIPs on one loadbalancer to VIPs on another.

I might not need the solution to this problem anymore, but this has been driving me crazy for the past week.

 

I've got a VIP on load balancer which has and irule. With a certain URI, it redirects to a VIP on another F5, which also has irules. After implementing the irules, I get the following when trying to open the browser with the redirect. "The connection has been reset."

 

 

when HTTP_REQUEST {

 

if {[HTTP::uri] contains "/foo/BAR" }

 

pool my-vip-redirect

 

} else {

 

pool my-vip

 

}

 

}

 

 

The pool, my-vip-redirect is a pool with a single server in it, the IP for the VIP on the other F5 listening on port 8443

 

 

Now on the second loadbalancer, where the second VIP resides

 

when HTTP_REQUEST {

 

if

 

!some elseif statement to other uris snipped!

 

elseif { ([HTTP::uri] contains "/foo/BAR") } { pool othervip-US-BAR-8443 }

 

!more elseif statements to other uris snipped!

 

}

 

 

As I said, this has been puzzling me all week, but it looks like they were planning to move the second VIP onto the same lb where the first LB resides, which should make things much easier. Would've been nice if they'd mentioned that beforehand, but I'd still like to know what was happening here to prevent it from working.

 

 

application delivery
dev
devops
iRules

19 Replies

Sort By
Show More
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 13, 2013
    Good catch. The filter should have been port 8443. Very interesting though. It doesn't appear to be SSL related if that's all you get. Do you have any IP filters on the internal LB? Do you see anything in the LTM logs on either? What happens if you remove the iRules from the internal LB? Can you post the configs for both VIPs?
  • atoth's avatar
    atoth
    Icon for Cirrus rankCirrus
    May 14, 2013

    We do have firewalls in our environment, which I don't have access to. As to IP filters, I'm not sure where I'd look for that.

     

     

    With the VIP in place, I can access the base URL directly. The second VIP's url I can also access directly, without the redirect.

     

     

    virtual myvip-443 {

     

    snat automap

     

    pool myvip-443

     

    destination "ipaddress1":https

     

    ip protocol tcp

     

    rules myvip-rules

     

    persist source_addr

     

    profiles {

     

    http {}

     

    serverssl {

     

    serverside

     

    }

     

    myvip-client {

     

    clientside

     

    }

     

    tcp {}

     

    }

     

    }

     

     

    VIP on other side.

     

     

    virtual othervip-8443 {

     

    snat automap

     

    destination "ipaddress2::pcsync-https

     

    ip protocol tcp

     

    rules otherrules-443

     

    persist cookie

     

    profiles {

     

    Othervip-client {

     

    clientside

     

    }

     

    http {}

     

    serverssl {

     

    serverside

     

    }

     

    tcp {}

     

    }

     

    }

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 14, 2013
    If you try a cURL from the management shell of the first to access the VIP of the second, that should tell you if there's an ACL in the way. Use the -k option to get past the SSL errors.
  • atoth's avatar
    atoth
    Icon for Cirrus rankCirrus
    May 14, 2013
    curl -k https://ip-address1/redirect

     

    curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
  • atoth's avatar
    atoth
    Icon for Cirrus rankCirrus
    May 14, 2013

    curl -k https://ipaddress:8443/redirect

     

    curl: (7) couldn't connect to host

     

     

    I didn't specifically include the 8443 earlier. The pool member in the redirect is already specified for 8443

     

     

    EDIT: On a sidenote, I don't seem to be able to reach the pool servers on the second LB directly from the 1st LB. I don't think this is an issue. since this should all be going through the SNAT, and not talking directly to each other.

     

     

    traceroute "1st pool member"

     

    traceroute to "1st pool member" ("1st pool member"), 30 hops max, 40 byte packets

     

    1 "2nd Loadbalancer" 1786.145 ms !H 1786.139 ms !H *

     

     

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 14, 2013
    If you sit on the first LB's management shell and cURL to the VIP on the second LB, you'll want to specify the port if it isn't 443. This will also source from the self-IP of the first LB, so SNATting won't be an issue. You should be able to access the VIP (not the pool members) on the second LB from the first LB, and see the content that the second LB is load balancing. If you can't access the content through the VIP from the first LB, then nothing else will work either.

     

     

    first LB shell cURL -> second VIP -> internal pool

     

  • atoth's avatar
    atoth
    Icon for Cirrus rankCirrus
    May 16, 2013
    Had a coworker look at it. Figured out what went wrong. I needed to do a SNAT statement like so.

     

     

    when HTTP_REQUEST {

     

    if {[HTTP::uri] contains "/foo/BAR" }

     

    snat "ip address of my-vip"

     

    pool my-vip-redirect

     

    } else {

     

    pool my-vip

     

    }

     

    }