# Problem with round robin + load balance [kind of offtopic]

## oandarilho01

Hi!

I have this scenario:

2 ISP links, both are plugged in gentoo firewalls, which delivers it to a RV042 cisco router. This cisco router is doing load balance, and I have a gentoo web server behind another gentoo firewall behind this cisco router.

This web server should be reached through a hostname configured with round robin to serve the public IPs of the ISP links.

The problem is that when I try to open the web page, the connection come through a given IPS link, but some of the web server reply packets are being directed to the other ISP link, causing slowliness or even failures.

I've tried to disable SPI (stateful packet inspection) on cisco router, but nothing happens.

I'm not sure whether it's a cisco issue or a linux issue. I appreciate some tips.

Thanks in advance

----------

## ShadowCat8

Greetings,

It's been a while since I've had to worry about such things, but one question I would have in regards to this is:

Who is the SOA (Start-Of-Authority) on your domain?  You?  Or one of the ISPs?  

I know the round-robin should be set up as part of the DNS zonefile entries with each server being aliased to the public hostname of the site.  IIRC, you then can add 'preference values' (READ: "weights") to the entries to guide which will be used for each inbound request.

HTH.  Let us know.

----------

## oandarilho01

I am the SOA. Actually one of the ISP is the company where I work.

Note that the problem is not directly with round robin, as the access are been balanced correctly, in a good aleatory fashion.

But misteriously, some of the web server reply packets are been misleading. I can't figure out by whom.

The network schema is something like that:

client got roundrobinIP1 -> ISP1 gateway/modem -> ISP1 gentoo FW1 -> cisco -> internal firewall -> webserver

Some reply packets do this way:

webserver -> internal firewall -> cisco -> ISP2 gentoo FW2 -> client

Am I clear? I know that it seems a bit confuse...

I noticed that almost stantly when I call the roundrobin hostname on the browser, I get tcpdump traffic on both ISP1 gentoo FW1 and ISP2 gentoo FW2, but the packets on the second are just SYN tries that are unrelated.

This is the reason I believe someone, maybe cisco is not respecting the connectios..

----------

## AngelKnight

In normal layer-3 forwarding, the decision is based solely on the destination of a given IP packet.  There's no accounting for what that IP packet is in response to; this has no effect on a standard routing decision and a normal IP forwarder doesn't care.

If you need the source IP address to influence the forwarding decision w.r.t. which ISP link to use, you may need to properly configure policy routing on one or more devices in this setup.

Are both ISPs willing to let you emit return traffic with the source set as an IP address belonging to the *other* ISP?  If this permission is definitely in place, what's the concern?

----------

## oandarilho01

 *AngelKnight wrote:*   

> In normal layer-3 forwarding, the decision is based solely on the destination of a given IP packet.  There's no accounting for what that IP packet is in response to; this has no effect on a standard routing decision and a normal IP forwarder doesn't care.
> 
> If you need the source IP address to influence the forwarding decision w.r.t. which ISP link to use, you may need to properly configure policy routing on one or more devices in this setup.

 

I would not like to "need" to influence the forward decision. I understand that if the connection came through one ISP, it has to go back through the same ISP until the end. I'll search something related to the policy routing configuration in this schema.

 *AngelKnight wrote:*   

> Are both ISPs willing to let you emit return traffic with the source set as an IP address belonging to the *other* ISP?  If this permission is definitely in place, what's the concern?

 

No, that's the problem! I do believe that the gentoo firewall between the webserver and the cisco router is delivering to it packets with the correct IPs, but even this way the packets get routed to the other ISP link...

----------

