[Lxc-users] Slow response times (at least, from the LAN) to LXC containers

Michael B. Trausch mike at trausch.us
Wed Mar 10 18:57:43 UTC 2010

On 03/10/2010 12:06 PM, Daniel Lezcano wrote:
> Michael B. Trausch wrote:
>> Here is ping output showing the problem:
>> mbt at fennel:~$ time ping -c 4 spicerack.trausch.us
>> PING spicerack.trausch.us ( 56(84) bytes of data.
>> From icmp_seq=2 Redirect Host(New nexthop:
>> From icmp_seq=3 Redirect Host(New nexthop:
>> 64 bytes from icmp_seq=4 ttl=64 time=2.27 ms
>> --- spicerack.trausch.us ping statistics ---
>> 4 packets transmitted, 1 received, 75% packet loss, time 11073ms
>> rtt min/avg/max/mdev = 2.278/2.278/2.278/0.000 ms
>> real 0m21.144s
>> user 0m0.000s
>> sys 0m0.020s
>> Now, this is pinging from my laptop. When I ping from the outside
>> world, it always seems to work:
> Mmh, some informations are missing to investigate.
> The redirect you receive means the router find an optimized route for
> the packet you sent to him, so the icmp redirect will trigger the kernel
> to create a new route for these packets. Maybe the route is not created
> in the right container ? Can you check where is created this route ?
> * ip route table show all
> or
> * route -Cn

The routing tables are automatically setup (that is, they are setup by 
Debian's /etc/network/interfaces) based on the network configuration 

Here is the routing table from the spicerack.trausch.us container:
mbt at spicerack:~$ ip route show all dev eth0  proto kernel  scope link  src dev eth1  proto kernel  scope link  src
default via dev eth0  metric 100

Here is the routing table from the container's host:
mbt at saffron:~$ ip route show all dev br0  proto kernel  scope link  src dev virbr0  proto kernel  scope link  src
default via dev br0  metric 100

> Can you give a summary of the network topolgy (IP of each container and
> routes ) ?

The network router has the global IP address and an 
address on the LAN of  It is an unfortunate piece of 
hardware supplied by my ISP (it is a cable modem and router 
combination).  I have a /29 from my ISP, of which they use one address 
(.190) and I use the other 5 (.185 through .189).  Anything that doesn't 
have a static IP address has a address, and is NAT'd 
through .190.

> For example, where is located ?

It is at the network edge, and as noted above has also the global IP 

> Is your host configured as a router ?

The LXC host has IPv4 forwarding enabled:
mbt at saffron:~$ cat /proc/sys/net/ipv4/conf/all/forwarding

Interestingly enough, IPv6 forwarding was _not_ enabled on the host 
node, despite the fact that I am pretty sure that I enabled it.  It is 
enabled now, though:

mbt at saffron:~$ cat /proc/sys/net/ipv6/conf/all/forwarding

> Probably more questions will come later :)

Okay, that's fine.  I will answer anything/everything I can.  As far as 
I can tell, I am only having this problem on the LAN when I try to reach 
one of the global IP addresses.  Unfortunately, that's the most annoying 
part.  Most of my things on those addresses are things that I use mostly 
at home, but sometimes need to use out and about, which is why they are 
on my Web server in the first place.  :-)

>> What I don't get is why I am receiving these redirects from ping. I
>> never get them when pinging 172.16.0.x addresses that are in LXC
>> containers on that system. And I never got these redirects before when
>> I was running containers in OpenVZ.
>> Also, if I try to ping that same interface's IPv6 addresses, I get
>> failures (Address unreachable), no matter if I ping the private or the
>> global one. However, I can reach ipv6.google.com just fine, and it is
>> going through that computer to get to my tunnel to Hurricane Electric.
>> It has to, since that container is my only IPv6 route to the world and
>> the tunnel endpoint is that container's global IP address.

It seems that this issue might be fixed; I guess the host system didn't 
remember to enable forwarding after the last reboot.  Though that is 
even more confusing:  IPv6 forwarding should not be required on the host 
to ping an Ethernet interface on the bridge that has IPv6, because the 
host should not have to forward that.  Only a container should need the 
IPv6 forwarding enabled if the container is the thing that is routing 
between your own IPv6 network and the IPv6 Internet.

>> I am completely confused on this one. I don't know where to look next.
> Let's try to solve the problems one by one.

Michael B. Trausch                                    ☎ (404) 492-6475

More information about the lxc-users mailing list