<div><br></div>Dear Fajar,<div>Thank you !</div><div><br><br><div class="gmail_quote">2012/6/12 Fajar A. Nugraha <span dir="ltr"><<a href="mailto:list@fajar.net" target="_blank">list@fajar.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Jun 12, 2012 at 12:23 PM, Sébastien Montagne<br>
<<a href="mailto:sebastien.montagne@gmail.com">sebastien.montagne@gmail.com</a>> wrote:<br>
><br>
> It seems that ARP reply is not seen in guest's eth0... </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, fix that :)<br></blockquote><div>
<br></div><div>:)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Running route add -host 91.121.99.254 eth0<br>You shouldn't need to execute that command. Ever.</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Running route del -net <a href="http://91.121.99.0/24" target="_blank">91.121.99.0/24</a> gw 0.0.0.0 eth0<br>... and neither does that command. Ever.</div></blockquote><div><br></div><div>Okay :)</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Try tcpdump on your container's veth interface on host side (from your<br>
example, it was vethZkMxv3). This can help isolate whether the problem<br>
is in the host (e.g. host firewall) or veth pair (unlikely, but worth<br>
to try).</blockquote><div><br></div><div>Interesting !</div><div>ARP reply are seen on eth0 and br0, but not on vethDPuPYq.</div><div><br></div><div><div><b>host:~# tcpdump -n -i eth0 host 91.121.99.254</b></div><div>tcpdump: WARNING: eth0: no IPv4 address assigned</div>
<div>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</div><div>listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes</div><div>08:00:43.776390 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div>
<div>08:00:43.776796 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46</div><div>08:00:44.776395 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div><div>08:00:44.776832 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46</div>
<div>^C</div><div>4 packets captured</div><div>6 packets received by filter</div><div>0 packets dropped by kernel</div><div><b>host:~# tcpdump -n -i br0 host 91.121.99.254</b></div><div>tcpdump: WARNING: br0: no IPv4 address assigned</div>
<div>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</div><div>listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes</div><div>08:01:02.872298 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div>
<div>08:01:02.872828 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46</div><div>08:01:03.888286 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div><div>08:01:03.888887 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46</div>
<div>^C</div><div>4 packets captured</div><div>5 packets received by filter</div><div>0 packets dropped by kernel</div><div><b>host:~# tcpdump -n -i vethDPuPYq host 91.121.99.254</b></div><div>tcpdump: WARNING: vethDPuPYq: no IPv4 address assigned</div>
<div>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</div><div>listening on vethDPuPYq, link-type EN10MB (Ethernet), capture size 65535 bytes</div><div>08:01:12.936288 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div>
<div>08:01:13.936293 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div><div>08:01:14.936300 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div><div>08:01:15.952286 ARP, Request who-has 91.121.99.254 tell 91.121.99.167, length 28</div>
<div>^C</div><div>4 packets captured</div><div>5 packets received by filter</div><div>0 packets dropped by kernel</div></div><div><br></div><div><br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also:<br>
<br>
- disable firewall (e.g. iptables) in the host temporarily, if active<br></blockquote><div><br></div><div>I use Debian stable, on both host and guest.</div><div><br></div><div><br></div><div><div><b>host:~# iptables -L</b></div>
<div>Chain INPUT (policy ACCEPT)</div><div>target prot opt source destination </div><div><br></div><div>Chain FORWARD (policy ACCEPT)</div><div>target prot opt source destination </div>
<div><br></div><div>Chain OUTPUT (policy ACCEPT)</div><div>target prot opt source destination </div><div><b>host:~# ebtables -L</b></div><div>Bridge table: filter</div><div><br></div><div>Bridge chain: INPUT, entries: 0, policy: ACCEPT</div>
<div><br></div><div>Bridge chain: FORWARD, entries: 0, policy: ACCEPT</div><div><br></div><div>Bridge chain: OUTPUT, entries: 0, policy: ACCEPT</div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- try simple setup first, with IPv4 in both host and guest<br></blockquote><div><br></div><div>Would work if I had several IPv4 addresses.</div><div>(Working for years in a *very* similar server on the same provider... the only )</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- make sure the switch/router your server connected to supports<br>
multiple MAC on the same port<br></blockquote><div><br></div><div>I think this is the problem !</div><div>I know my provider (OVH) does such a filtering.</div><div><br></div><div>I think I understand : the vethDPuPYq interface has a (randomly?) generated MAC address, and it is blocked by my provider-s router.</div>
<div>Am I right ?</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you're using a hosted server, the last one might be the source of<br>
problem as many provider doesn't allow that.</blockquote><div><br></div><div>Yes :(</div><div><br></div><div><br></div><div>So, does that mean I should give up ?</div><div>Or could <i>ebtables</i> help ? Maybe theorically yes, but practically not easy ?</div>
<div>You say it's compicated. I don't know it at all.</div><div>Just started reading the man page : it says ebtables is less complicated than iptables :)</div><div><br></div><div>Do you think I should give up ?</div>
<div><br></div><div><br></div><div><br></div><div>Another information :</div><div>I know some people succeeded to setup an LXC server with IPv6 host and containers with LXC on Debian... on the same provider (OVH) !</div>
<div>
(in french) <a href="http://www.fiat-tux.fr/fr/2012/05/ipv6-ready/">http://www.fiat-tux.fr/fr/2012/05/ipv6-ready/</a></div><div>The approach seems to be different as eth0 and br0 seem not beeing linked together... eth0 and br0 have different IPv6 addresses... It seems that they keep eth0 and br0 independant, and that br0 is linked to dummy0. Also they enable options (forwarding and proxy_ndp) in /etc/sysctl.conf.</div>
<div>It sounds that I'm not (yet) good enough at networks to really understand all of that :)</div><div><br></div><div>But my situation is slightly different because I would like one of the containers to have a working IPv4 address.</div>
<div><br></div><div><br></div><div>In any cases :</div><div>Thank you again, Fajar !</div></div></div>