Dear Fajar,
Thank you !
2012/6/12 Fajar A. Nugraha <l...@fajar.net>
> On Tue, Jun 12, 2012 at 12:23 PM, Sébastien Montagne
> <sebastien.monta...@gmail.com> wrote:
> >
> > It seems that ARP reply is not seen in guest's eth0...
>
Well, fix that :)
>
:)
> > Running route add -host 91.121.99.254 eth0
> You shouldn't need to execute that command. Ever.
>
> > Running route del -net 91.121.99.0/24 gw 0.0.0.0 eth0
> ... and neither does that command. Ever.
>
Okay :)
> Try tcpdump on your container's veth interface on host side (from your
> example, it was vethZkMxv3). This can help isolate whether the problem
> is in the host (e.g. host firewall) or veth pair (unlikely, but worth
> to try).
Interesting !
ARP reply are seen on eth0 and br0, but not on vethDPuPYq.
*host:~# tcpdump -n -i eth0 host 91.121.99.254*
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:00:43.776390 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:00:43.776796 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46
08:00:44.776395 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:00:44.776832 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46
^C
4 packets captured
6 packets received by filter
0 packets dropped by kernel
*host:~# tcpdump -n -i br0 host 91.121.99.254*
tcpdump: WARNING: br0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:01:02.872298 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:01:02.872828 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46
08:01:03.888286 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:01:03.888887 ARP, Reply 91.121.99.254 is-at 00:00:0c:07:ac:01, length 46
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
*host:~# tcpdump -n -i vethDPuPYq host 91.121.99.254*
tcpdump: WARNING: vethDPuPYq: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vethDPuPYq, link-type EN10MB (Ethernet), capture size 65535
bytes
08:01:12.936288 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:01:13.936293 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:01:14.936300 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
08:01:15.952286 ARP, Request who-has 91.121.99.254 tell 91.121.99.167,
length 28
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
> Also:
>
> - disable firewall (e.g. iptables) in the host temporarily, if active
>
I use Debian stable, on both host and guest.
*host:~# iptables -L*
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
*host:~# ebtables -L*
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
> - try simple setup first, with IPv4 in both host and guest
>
Would work if I had several IPv4 addresses.
(Working for years in a *very* similar server on the same provider... the
only )
> - make sure the switch/router your server connected to supports
> multiple MAC on the same port
>
I think this is the problem !
I know my provider (OVH) does such a filtering.
I think I understand : the vethDPuPYq interface has a (randomly?) generated
MAC address, and it is blocked by my provider-s router.
Am I right ?
If you're using a hosted server, the last one might be the source of
> problem as many provider doesn't allow that.
Yes :(
So, does that mean I should give up ?
Or could *ebtables* help ? Maybe theorically yes, but practically not easy ?
You say it's compicated. I don't know it at all.
Just started reading the man page : it says ebtables is less complicated
than iptables :)
Do you think I should give up ?
Another information :
I know some people succeeded to setup an LXC server with IPv6 host and
containers with LXC on Debian... on the same provider (OVH) !
(in french) http://www.fiat-tux.fr/fr/2012/05/ipv6-ready/
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.
It sounds that I'm not (yet) good enough at networks to really understand
all of that :)
But my situation is slightly different because I would like one of the
containers to have a working IPv4 address.
In any cases :
Thank you again, Fajar !
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
