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. The script will create the VNIs for the guest network on the guest bridge and in the defined range and works as expected. 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.
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 > >> > > > > > -- p4nd0ra - the curious
