cancel
Showing results for 
Search instead for 
Did you mean: 

IP forwarding

frank_thyes_309
Nimbostratus
Nimbostratus

Hi Group,

 

we are migrating from PA address space to our own PI address space. Cooperation partners using domains like this: my.company.partner.com which point to our main IP address i.e 1.1.1.1, because I do not own the domain I can't change the IP by my own. Now we are migrating from 1.1.1.1 to lets assume 2.2.2.2 located on another HA pair of BigIPs.

 

The URL have to be the same because our application use it to decide which content have to be delivered.

 

How can I redirect / forward traffic for domain my.company.partner.com which points to 1.1.1.1 on bigip pair 1 to 2.2.2.2 on bigip pair 2 without changing the URL?

 

Any help is appreciated.

 

Best

 

Frank

 

22 REPLIES 22

What_Lies_Bene1
Cirrostratus
Cirrostratus

I'm not sure an iRule could be used to redirect the traffic as a HTTP redirect would by definition require a different FQDN. It's not a great solution but the only other thing I can think of is to configure a forwarding/performance Virtual Server and have the new Virtual Server (2.2.2.2) configured as the sole Member of a Pool attached to the old Virtual Server. Does that make sense?

 

It's not great but however you do it, there is an unwanted dependency on the old BIG-IP(s).

 

Hamish
Cirrocumulus
Cirrocumulus
You could... In advance, setup an A record in DNS that resolves to your old address. The get everyone who DOES own the domains to replace their A records with CNAMES.

 

 

Cutover then is as simple as changing the A record all the CNAMES resolve to.

 

 

Or do you still have a problem with even getting the partners to all update their DNS at any time?

 

 

H

nitass
F5 Employee
F5 Employee
can we just use "node" command pointing to 2.2.2.2? by the way, you will eventually change dns to 2.2.2.2, won't you?

 

 

e.g.

 

 

[root@ve10:Active] config b virtual bar list virtual bar { snat automap destination 1.1.1.1:80 ip protocol 6 rules myrule } [root@ve10:Active] config b rule myrule list rule myrule { when CLIENT_ACCEPTED { node 2.2.2.2 } }

frank_thyes_309
Nimbostratus
Nimbostratus

 

Yes the DNS will be changed after a short transition phase. You suggested solution does unfortunately not work. The old lb pair with the PA adresses don't know the new address. I assume your solution works like a charme when den new address space is reachable through a directly attached vlan.

 

Best Frank

 

nitass
F5 Employee
F5 Employee
The old lb pair with the PA adresses don't know the new address.

i thought 1.1.1.1 and 2.2.2.2 are public routable ip addresses (virtual server ip address).

 

frank_thyes_309
Nimbostratus
Nimbostratus

 

Yes that's the point, we need an independent solution. Our partners are big with very long processes... you know what I mean?

 

Best

 

Frank

 

frank_thyes_309
Nimbostratus
Nimbostratus

Thanks for you reply.

 

I'm afraid we are running into same problem as by the solution suggested from nitass. The old pair does not reach the new address through any directly attached vlan.

 

virtual fart {

 

destination 1.1.1.1:http

 

pool mypool

 

ip protocol tcp

 

}

 

 

pool mypool {

 

lb method observed

 

monitor all tcp_half_open

 

members {

 

2.2.2.2.2:80 {}

 

}

 

}

 

bigtop -n -once | grep 2.2.2.2.2

 

2.2.2.2.:80 11520 0 6 0 0 0 UP

 

 

$ curl -v my.partner.company.de

 

* About to connect() to my.partner.company.de port 80 (0)

 

* Trying 1.1.1.1... connected

 

> GET / HTTP/1.1

 

> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

 

> Host: my.partner.company.de

 

> Accept: */*

 

>

 

* Recv failure: Connection reset by peer

 

* Closing connection 0

 

curl: (56) Recv failure: Connection reset by peer

 

 

If I connect directly to 2.2.2.2 the request succeed.

 

Best Frank

 

frank_thyes_309
Nimbostratus
Nimbostratus

They are.

 

frank_thyes_309
Nimbostratus
Nimbostratus

They are, Maybe I'm doing it wrong.

 

virtual test {

 

destination 1.1.1.1:http

 

ip protocol 6

 

snat automap

 

rules myrule

 

}

 

rule myrule {

 

when CLIENT_ACCEPTED {

 

node 2.2.2.2:80

 

}

 

}

 

From the BigIP with the old address space the new one is reachable.

 

ping -c 2.2.2.2

 

PING 2.2.2.2 (2.2.2.2) 56(84) bytes of data.

 

64 bytes from 2.2.2.2: icmp_seq=1 ttl=61 time=12.7 ms

 

 

--- 2.2.2.2 ping statistics ---

 

1 packets transmitted, 1 received, 0% packet loss, time 0ms

 

rtt min/avg/max/mdev = 12.781/12.781/12.781/0.000 ms

 

 

Checking from a Host outside the network.

 

~$ curl -v test.abc.com

 

* About to connect() to test.abc.com port 80 (0)

 

* Trying 1.1.1.1... connected

 

> GET / HTTP/1.1

 

> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

 

> Host: test.abc.com

 

> Accept: */*

 

>

 

* Recv failure: Connection reset by peer

 

* Closing connection 0

 

curl: (56) Recv failure: Connection reset by peer

 

 

Any Ideas?

 

Best

 

Frank

 

nitass
F5 Employee
F5 Employee
can you try this on the old bigip?

 

 

curl -v http://2.2.2.2 -H "Host: test.abc.com"

frank_thyes_309
Nimbostratus
Nimbostratus

Here we go...

 

curl -v -I http://2.2.2.2 -H "Host: test.abc.com"

 

* About to connect() to 2.2.2.2 port 80

 

* Trying 2.2.2.2... connected

 

* Connected to 2.2.2.2 (2.2.2.2) port 80

 

> HEAD / HTTP/1.1

 

> User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

 

> Accept: */*

 

> Host: test.abc.com

 

>

 

< HTTP/1.1 200 OK

 

HTTP/1.1 200 OK

 

< Date: Sat, 13 Oct 2012 13:18:37 GMT

 

Date: Sat, 13 Oct 2012 13:18:37 GMT

 

< Server: Apache/2.2.16 (Debian)

 

Server: Apache/2.2.16 (Debian)

 

< Last-Modified: Sat, 13 Oct 2012 07:36:35 GMT

 

Last-Modified: Sat, 13 Oct 2012 07:36:35 GMT

 

< ETag: "501f1-b1-4cbebdd2846c0"

 

ETag: "501f1-b1-4cbebdd2846c0"

 

< Accept-Ranges: bytes

 

Accept-Ranges: bytes

 

< Content-Length: 177

 

Content-Length: 177

 

< Vary: Accept-Encoding

 

Vary: Accept-Encoding

 

< Content-Type: text/html

 

Content-Type: text/html

 

< X-Pad: avoid browser bug

 

X-Pad: avoid browser bug

 

 

* Connection 0 to host 2.2.2.2 left intact

 

* Closing connection 0

 

 

nitass
F5 Employee
F5 Employee
have you configured tmm route for 2.2.2.2 (e.g. default route) on the old bigip (i am not sure when you ping 2.2.2.2, did it use mgmt route or tmm route)?

 

 

can you try tcpdump on the old bigip while accessing http://1.1.1.1?

 

 

to screen

 

tcpdump -nni 0.0:nnn -s0 host 1.1.1.1 or host 2.2.2.2 and port 80

 

 

to file

 

tcpdump -nni 0.0:nnn -s0 -w /var/tmp/output.pcap host 1.1.1.1 or host 2.2.2.2 and port 80

frank_thyes_309
Nimbostratus
Nimbostratus
The old bigip device is using a default route, reachable through the self ip 123.123.123.123

 

 

[root@lb2:Active] config tcpdump -nni 0.0:nnn -s0 host 1.1.1.1 or host 2.2.2.2 and port 80

 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

 

listening on 0.0:nnn, link-type EN10MB (Ethernet), capture size 65535 bytes

 

17:51:22.351698 IP 123.123.123.123.55841 > 2.2.2.2.80: S 3039961864:3039961864(0) win 5840 out slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.364182 IP 2.2.2.2.80 > 123.123.123.123.55841: S 1491322061:1491322061(0) ack 3039961865 win 5792 in slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.364714 IP 123.123.123.123.55841 > 2.2.2.2.80: . ack 1 win 46 out slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.369011 IP 123.123.123.123.55841 > 2.2.2.2.80: P 1:156(155) ack 1 win 46 out slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.381035 IP 2.2.2.2.80 > 123.123.123.123.55841: . ack 156 win 429 in slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.381317 IP 2.2.2.2.80 > 123.123.123.123.55841: P 1:284(283) ack 156 win 429 in slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.381771 IP 123.123.123.123.55841 > 2.2.2.2.80: . ack 284 win 54 out slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.385329 IP 123.123.123.123.55841 > 2.2.2.2.80: F 156:156(0) ack 284 win 54 out slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.397684 IP 2.2.2.2.80 > 123.123.123.123.55841: F 284:284(0) ack 157 win 429 in slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

17:51:22.397817 IP 123.123.123.123.55841 > 2.2.2.2.80: . ack 285 win 54 out slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094

 

nitass
F5 Employee
F5 Employee
17:51:22.381317 IP 2.2.2.2.80 > 123.123.123.123.55841: P 1:284(283) ack 156 win 429 in slot1/tmm1 lis= flowtype=130 flowid=D10F1C0 peerid=1A3A6E40 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:D4121204 peerlocal=00000000:00000000:0000FFFF:BCAEB90A remoteport=55841 localport=80 proto=0 vlan=4094 is this not http response?

frank_thyes_309
Nimbostratus
Nimbostratus
Sure it is. I did what you asked me to.

 

 

From the old device "curl -v -I http://2.2.2. 2-H "Host: test.abc.com" while dumping.

nitass
F5 Employee
F5 Employee
From the old device "curl -v -I http://2.2.2. 2-H "Host: test.abc.com" while dumping.sorry to confuse. actually, i mean "curl -v -I http://1.1.1.1 -H "Host: test.abc.com" while running "tcpdump -nni 0.0 host 1.1.1.1 or host 2.2.2.2 and port 80" (to screen) or "tcpdump -nni 0.0:nnn -s0 -w /var/tmp/output.pcap host 1.1.1.1 or host 2.2.2.2 and port 80" (to file).

frank_thyes_309
Nimbostratus
Nimbostratus
[root@lb2:Active] config curl -v -I http://1.1.1.1 -H "Host: test.abc.com"

 

* About to connect() to 1.1.1.1 port 80

 

* Trying 1.1.1.1... connected

 

* Connected to 1.1.1.1 (1.1.1.1) port 80

 

> HEAD / HTTP/1.1

 

> User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

 

> Accept: */*

 

> Host: test.abc.com

 

>

 

* Empty reply from server

 

* Connection 0 to host 1.1.1.1 left intact

 

curl: (52) Empty reply from server

 

* Closing connection 0

 

 

[root@lb2:Active] config tcpdump -nni 0.0:nnn -s0 host 1.1.1.1 or host 2.2.2.2 and port 80

 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

 

listening on 0.0:nnn, link-type EN10MB (Ethernet), capture size 65535 bytes

 

20:59:12.019359 IP 10.0.35.2.41072 > 2.2.2.2.80: S 3247471255:3247471255(0) win 4380 out slot1/tmm0 lis=vs_1.1.1.1_8 flowtype=128 flowid=13B2F540 peerid=2E4AB5C0 conflags=924 inslot=0 inport=0 haunit=1 peerremote=00000000:00000000:0000FFFF:D4120404 peerlocal=00000000:00000000:0000FFFF:D4120412 remoteport=41072 localport=80 proto=0 vlan=4094

 

20:59:15.019116 IP 10.0.35.2.41072 > 2.2.2.2.80: S 3247471255:3247471255(0) win 4380 out slot1/tmm0 lis=vs_1.1.1.1_8 flowtype=128 flowid=13B2F540 peerid=2E4AB5C0 conflags=924 inslot=0 inport=0 haunit=1 peerremote=00000000:00000000:0000FFFF:D4120404 peerlocal=00000000:00000000:0000FFFF:D4120412 remoteport=41072 localport=80 proto=0 vlan=4094

 

20:59:18.218981 IP 10.0.35.2.41072 > 2.2.2.2.80: S 3247471255:3247471255(0) win 4380 out slot1/tmm0 lis=vs_1.1.1.1_8 flowtype=128 flowid=13B2F540 peerid=2E4AB5C0 conflags=924 inslot=0 inport=0 haunit=1 peerremote=00000000:00000000:0000FFFF:D4120404 peerlocal=00000000:00000000:0000FFFF:D4120412 remoteport=41072 localport=80 proto=0 vlan=4094

 

20:59:21.419283 IP 10.0.35.2.41072 > 2.2.2.2.80: S 3247471255:3247471255(0) win 4380 out slot1/tmm0 lis=vs_1.1.1.1_8 flowtype=128 flowid=13B2F540 peerid=2E4AB5C0 conflags=924 inslot=0 inport=0 haunit=1 peerremote=00000000:00000000:0000FFFF:D4120404 peerlocal=00000000:00000000:0000FFFF:D4120412 remoteport=41072 localport=80 proto=0 vlan=4094

 

 

Looks like the device send the request to the outside host using the wrong interface. I expected 123.123.123.123 instead of the internal address 10.0.35.2

nitass
F5 Employee
F5 Employee
Looks like the device send the request to the outside host using the wrong interface. I expected 123.123.123.123 instead of the internal address 10.0.35.2is route for 2.2.2.2 in same subnet as 123.123.123.123 interface? 123.123.123.123 is tmm interface (selfip), isn't it?

nitass
F5 Employee
F5 Employee
not sure if it is relevant. anyway, just in case if you have not yet seen it.

 

 

sol7336: The SNAT Automap feature may use an unintended self IP address

 

http://support.f5.com/kb/en-us/solutions/public/7000/300/sol7336.html

frank_thyes_309
Nimbostratus
Nimbostratus
2.2.2.2 is a public address and 123.123.123.123 is one of the external public addresses on the device. On this box we have a default gw configured. Unknown public IP address should be routed to the default gateway, don't they?

 

 

From sol7336: If the selected address resides on the ingress VLAN, the BIG-IP system will not SNAT the traffic.

 

 

Incoming interface and outgoing interface are the same, looks like that's the point. Do you have a idea how I can get it working nevertheless?

nitass
F5 Employee
F5 Employee
do you have floating selfip on *every* vlan?

 

 

the tcpdump shows bigip sends traffic out on vlan 4094 which i guess it is external vlan. so, i think the problem is not wrong *interface* but wrong *snat ip address*. can you try to use snatpool instead of snat automap (under virtual server configuration)?

frank_thyes_309
Nimbostratus
Nimbostratus

 

Snatpool, bingo. You saved me a lot of work, thank you very much!

 

 

snatpool mysnat {

 

members $self_ip_from_network_1.1.1.0/24

 

}

 

virtual myvirt {

 

snatpool mysnat

 

destination 1.1.1.1:http

 

ip protocol tcp

 

rules myrule

 

}

 

rule myrule {

 

when CLIENT_ACCEPTED {

 

node 2.2.2.2 80

 

}

 

}

 

 

Best

 

Frank