LC SNAT Issue

Hi,

 

 

Did you get this resolved?

 

 

If not, is this the originating request or the response that's going out the wrong ISP link? For outbound it would be up to pool configuration if you have a self IP on the same subnet ast the destination, or the routing table for a non-local destination. For the response LTM would use auto-lasthop to send the response out the same VLAN as the request came in on.

 

 

Aaron

Thanks for the reply, no this is not resolved, I am using a work around but its not ideal. This is for outbound traffic, the connection is nated to the correct SNAT address but then still following the default gateway pool.

Can you post an anonymized copy of the VIP (b virtual VIP_NAME list), gateway pool (b pool POOL_NAME list) and routing table (netstat -nr) to clarify the configuration?

 

 

Thanks,

 

Aaron

List did not work for virtual so I provided the show, let me know if this not what you are looking for. The VIP is currently disable. Thanks for your help!

 

 

 

VIRTUAL 1.1.1.153 UNIT 1

 

| (cur, max, limit, tot) = (0, 280, 0, 460634)

 

| (pckts,bits) in = (11542797, 82444558080), out = (8473146, 5240694720)

 

| PASS ANY IP: disabled

 

+---+--> SERVICE 25 DISABLED

 

| hw_acceleration none

 

| (cur, max, limit, tot) = (0, 1532, 0, 1051663)

 

| (pckts,bits) in = (23376301, 166367499392), out = (17318713, 10647662944)

 

+---+--> POOL pgcscan3

 

+--> MEMBER 192.168.1.24:25 DOWN

 

(cur, max, limit, tot) = (0, 2161, 0, 4915637)

 

(pckts,bits) in = (13720958, 23449128176), out = (11016783, 94175584536)

 

 

pool default_gateway_pool {

 

lb_method ratio_member

 

min_active_members 1

 

persist simple

 

simple_timeout 900

 

nat disable

 

member 2.2.2.161:0 ratio 2

 

member 3.3.3.1:0

 

member 4.4.4.1:0

 

 

Internet:

 

Destination Gateway Flags MTU If

 

default 3.3.3.1 UGSp 1500 vlan4

 

default 2.2.2.161 UGSp 1500 vlan0

 

default 4.4.4.1 UGSp 1500 vlan2

 

default 1.1.1.1 UGS 1500 vlan2

 

4.4.4/24 link31 UC 1500 vlan2

 

4.4.4.1 0.11.21.29.3c.1a UHLc 1500 vlan2

 

4.4.4.190 link31 UHLc 1500 vlan2

 

4.4.4.191 link31 UHLc 1500 vlan2

 

2.2.2.160/27 link29 UC 1500 vlan0

 

2.2.2.161 0.11.21.2e.38.54 UHLc 1500 vlan0

 

2.2.2.181 0.1.d7.27.70.1 UHLc 1500 lo0

 

3.3.170/23 link33 UC 1500 vlan4

 

3.3.3.1 0.30.71.e1.90.0 UHLc 1500 vlan4

 

127 127.0.0.1 UGRS 4352 lo0

 

127.0.0.1 127.0.0.1 UH 4352 lo0

 

1.1.1/24 link31 UC 1500 vlan2

 

1.1.1.1 0.11.21.29.3c.1b UHLc 1500 vlan2

 

1.1.1.143 link31 UHLc 1500 vlan2

 

1.1.1.170 0.16.36.d3.2d.83 UHLc 1500 vlan2

 

1.1.1.181 0.1.d7.27.70.1 UHLc 1500 lo0

 

192.168.1 192.168.100.1 UGS 1500 vlan1

It looks like you're using simple (source address) persistence on the default gateway pool. Can you change this to destination address persistence and see if the issue clears?

 

 

Thanks,

 

Aaron

I will try, is there a way to clear current persistance connections?

You can use the 'b persist' command to manage the persistence table and 'b persist help' for command usage details. If you change the persistence method on the pool though, I don't think any other persistence record from a different persistence method would be considered valid. So you probably don't need to clear the records.

 

 

Aaron