Op 04/08/2023 om 13:07 schreef Curious Pandora:
Hello,
yes we utilize BGP and EVPN until the host. Then the vxlans are configured
for public/management/guest networks and the corresponding bridges are
created on top of those vnis.
But why do you create VXLAN devices for the public/guest network?
CloudStack creates these for you.
The script will create the VNIs for the guest network on the guest bridge
and in the defined range and works as expected.
You mean the script of CloudStack or your own script?
This whole part works. The problem is that if you define the tags in the
physical network for each of those bridges the agent is looking for the
underlying interfaces on each bridge.
For some reason the client is looking only for interfaces starting with eth*,
bond*, team*, vlan*, em*, p*p*, ens*, eno*,
enp*, or enx*. A workaround is to remove all tags from the public
network in cloudstack and define them manually in the agent.properties.
This is not the intended usage afaik.
Aha, that might probably be it, I've never used the traffic labels in
CloudStack.
But you are using Frr for EVPN/BGP on the host I assume?
Wido
On Fri, Aug 4, 2023 at 12:08 PM Wido den Hollander <[email protected]> wrote:
Op 04/08/2023 om 09:05 schreef Curious Pandora:
Well, after pocking around it looks that the problem is in the
cloudstack-agent.
When calling for com.cloud.agent.api.CheckNetworkCommand it is expected
to
find interfaces such as eth*, bond*, team*, vlan*, em*, p*p*, ens*,
eno*,
enp*, or enx*
In our case the interface is starting from vni*,
Maybe it's a good idea to add vni* in the list of accepted interfaces and
update the documentation to reflect that.
Can you explain a bit more about the topology? Because by default you
should not be creating vni/vxlan devices, cloudstack (modifyvxlan.sh)
should be doing this for you.
How are you using VXLAN in your environment? With BGP and EVPN up until
the host?
Wido
On Tue, Aug 1, 2023 at 9:45 AM Wido den Hollander <[email protected]>
wrote:
Op 31-07-2023 om 11:57 schreef Curious Pandora:
Thanks for the reply. For some strange reason cloudstack agent doesn't
work with the bridge interfaces that the vnis are attached to.
But how did you connect them? For each VNI CloudStack should create a
separate bridge on the fly. That's done by that modifyvxlan.sh script.
Is the broadcast domain for the network set to vxlan://1234 where 1234
is your VNI ID?
Wido
From the management server:
Failed to handle host connection:
com.cloud.exception.ConnectionException: Incorrect Network setup on
agent, Reinitialize agent after network names are setup, details : Can
not find network: brguestl2
From the host side:
bridge name bridge id STP enabled interfaces
brguestl2 8000.a2d96b610d2a no
vniguestl2
On Mon, Jul 31, 2023 at 12:10 PM Wido den Hollander <[email protected]
<mailto:[email protected]>> wrote:
Op 31/07/2023 om 10:03 schreef Curious Pandora:
> Hello,
>
> just a quick confirmation if the VXLAN plugin can apply to
> management/storage/public networks as well or is only
implemented
for guest
> networks.
>
Keep in mind that the 'plugin' is just a Shell script
(modifyvxlan.sh)
which is executed upon VM launch.
All it does is create some Linux bridges and VXLAN interfaces
on-demand,
but that's it.
If you want to work with VXLAN you will probably have to do some
work
manually on the hypervisors to get BGP and EVPN working as well.
For mgmt and storage traffic you could then use systemd-networkd
to
create VXLAN devices where needed.
That's how I do it :-)
Wido
> Kind regards,
>
>
--
p4nd0ra - the curious
