OpenVZ Forum


Home » General » Support » time to live exceeded (2 containers dont speak to each other)
Re: time to live exceeded [message #39479 is a reply to message #39464] Fri, 30 April 2010 13:11 Go to previous messageGo to previous message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Hello,

look, I'd better try to explain you what's going on. I hope it'll shed some light on your problem.

As you might have noticed each of your VE uses venet0 interface to communicate with external world. venet0 is just nothing but point-to-point connection. So, everything is put inside venet0 on the HN goes to the proper VE (venet0 driver reads destination ip address and puts a network packet to the proper VE).
Let's check an outgoing traffic. If a VE issues a network packet it goes directly to venet0 interface (look at the default gateway inside your VE). But on the HN you have a table 6 which should catch all traffic going from 172.16.0.26 and 172.16.0.21. There is a singe route inside this table ("ip route add default dev eth1 via 172.16.0.254 table 6"). Hence all network packets going from the VE (172.16.0.21 or .26) are to be sent to 172.16.0.254.
At the same moment there are the following routes on your HN
Quote:

[root@watcher ~]# ip route
172.16.0.21 dev venet0 scope link
193.40.142.130 dev venet0 scope link
193.40.142.226 dev venet0 scope link
172.16.0.26 dev venet0 scope link


that means that traffic which is intended to your VEs should go through venet0 interface.


Let's consider your case. You try to communicate from VE 193.40.142.130 to VE 172.16.0.26. The network packet goes to HN and then according to routing table it should pass to venet0 again ("172.16.0.26 dev venet0 scope link"). The answer from the VE goes to HN but at this moment the routing decision should obey the routing rule in the table 6 and network packet goes to 172.16.0.254. I don't know what's going on on that node but eventually it routes the packet somewhere else and the packet never reaches 193.40.142.130 => the VE cannot catch the answer.
I suppose the same situation occurs when you try to ping 172.16.0.26 from 172.16.0.21.

P.S. please use tcpdump utility to trace network traffic. It really helps you find out where the packet is lost.

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Previous Topic: usb speed after kernel upgrade
Next Topic: 2.6.18 - > 2.6.24 devnodes trouble
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Dec 21 23:47:57 GMT 2025

Total time taken to generate the page: 0.24363 seconds
Powered by FUDforum Powered by Virtuozzo Containers