Re: [lvs-users] ipvsadm and packets leaving a gre tunnel

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] ipvsadm and packets leaving a gre tunnel
From: Joseph Mack NA3T <jmack@xxxxxxxx>
Date: Tue, 22 Jul 2008 07:16:54 -0700 (PDT)
On Tue, 22 Jul 2008, Marco Lorig wrote:

Iīve read the section but as i understand correctly the only solution in a LVS-NAT env is to set the MTU by hand on each route or interface on the realservers, which unfortunately I havenīt access to.

Ratz's solution is on the director, and sets the MTU for the route.

We have been running this env since 2002 with Kernel 2.4.19 with no problems (running director on gre_interface). Actually we have upgraded our systems to kernel 2.6.18 which causes this problems.


a lot of stuff broke going to 2.6.x

The gre tunnel exists between the directors because of failover reasons ( each director is located in a seperate datacenter interconnected by WAN).

Copying files like this:
Client ---scp----> Director ---GRE Tunnel nopmtudisc --> Director ----scp ---> 
Server and vice versa.

not sure what you're doing here. Is it one connection with this route?


I assume you have two directors in some standard failover setup and only one is directing when your LVS is up?

works fine but if the ipvsadm is enabled on the second director to serve multiple servers, the mtu problem happens.

the copy has nothing to do with LVS? ie you can do the copy when there is nothing in the ipvsadm table in the 2nd (inactive) director, but as soon as you put entries into ipvsadm on the backup director, the gre tunnel breaks?

If so, are there any entries you can put into ipvsadm that won't break the tunnel? Are the any which guarantee to break the tunnel? What if the ipvsadm table is empty on the active director?


Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at
Homepage It's GNU/Linux!

<Prev in Thread] Current Thread [Next in Thread>