Greetings all,
Trying to isolate a condition whereby a container providing firewall services
seems to stop processing traffic for a short time. We keep getting the below
information in /var/log/syslog of the server running the firewall. The IP
addresses shown match the network interfaces of t
On Sun, Sep 24, 2017 at 03:27:27PM -0400, Ron Kelley wrote:
> Greetings all,
>
> Trying to isolate a condition whereby a container providing firewall services
> seems to stop processing traffic for a short time. We keep getting the below
> information in /var/log/syslog of the server running th
Thanks Stephane.
Here is a “lxc network list” on the hosts:
rkelley@LXD-QA-Server-04:~$ lxc network list
++--+-+-+-+
| NAME | TYPE | MANAGED | DESCRIPTION | USED BY |
++--+-+-+-+
| eth0 | physical | NO
Hi,
Ok, so you're doing your own VXLAN youtside of LXD and then connecting
containers directly to it.
The kernel error is very odd for unicast vxlan... there's really no
reason for it to ever use the other interface...
So I'm assuming the 10.250.1.21 IP is on eth0 and 172.18.22.21 on eth1
(or th
Looks like I mistakenly said unicast. In fact, we are using multicast group IP
(239.0.0.1) to setup our VXLAN interfaces (please see below). Also, in the
example below, 10.250.1.21 is bound the eth0 (our management interface) and
172.18.22.21 is bound to eth1 (VXLAN interface). We have 8 serv
Things look fine. I'm not sure why the kernel would still be looking at
eth0 when you specifically told it to setup the tunnel on eth1...
I wonder if adding a static route for the multicast address to go to
eth1 would fix that somehow.
On Tue, Sep 26, 2017 at 12:48:01PM -0400, Ron Kelley wrote:
