<div dir="ltr">Thank you Sean for the detailed explanation,<div><br></div><div>I agree on LACP mode and I think Active-Standby would be a better and safer option for me. </div><div><br></div><div>Yes, as you said telco is abusing many neutron rules and i think i am one of them because pretty much we are running telco applications :) As I said, it's a private cloud so I can break and bend rules to just make applications available 24x7.  We don't have any multi-tenancy where I should be worried about security. </div><div><br></div><div>Last question, Related MAC Address change because neutron doesn't allow change of Mac address correct so i have to set the same MAC Address on both sriov port. As per reference blog. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 10, 2023 at 12:37 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2023-03-10 at 11:54 -0500, Satish Patel wrote:<br>
> Hi Sean,<br>
> <br>
> I have a few questions and they are in-line. This is the reference doc i am<br>
> trying to achieve in my private cloud -<br>
> <a href="https://www.redpill-linpro.com/techblog/2021/01/30/bonding-sriov-nics-with-openstack.html" rel="noreferrer" target="_blank">https://www.redpill-linpro.com/techblog/2021/01/30/bonding-sriov-nics-with-openstack.html</a><br>
^ is only safe in a multi tenant envionment if <br>
<a href="https://docs.openstack.org/neutron/latest/configuration/ml2-conf.html#ml2.tenant_network_types" rel="noreferrer" target="_blank">https://docs.openstack.org/neutron/latest/configuration/ml2-conf.html#ml2.tenant_network_types</a> does not container vlan or flat.<br>
<br>
it is technially breaking neutron rules for how to use phsyents.<br>
<br>
in private cloud where tenatn isolation is not required operators have abused this for years for things like selecting numa nodes<br>
and many other usecase which are unsafe in a public cloud.<br>
<br>
> <br>
> On Fri, Mar 10, 2023 at 9:02 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
> <br>
> > On Fri, 2023-03-10 at 08:30 -0500, Satish Patel wrote:<br>
> > > Thanks Sean,<br>
> > > <br>
> > > I don't have NIC which supports hardware offloading or any kind of<br>
> > feature.<br>
> > > I am using intel nic 82599 just for SRIOV and looking for bonding<br>
> > > support which is only possible inside VM. As you know we already run a<br>
> > > large SRIOV environment with openstack but my biggest issue is to upgrade<br>
> > > switches without downtime. I want to be more resilient to not worry<br>
> > > about that.<br>
> > > <br>
> > > Do you still think it's dangerous or not a good idea to bond sriov nic<br>
> > > inside VM?  what could go wrong here just trying to understand before i<br>
> > go<br>
> > > crazy :)<br>
> > lacp bond mode generaly dont work fully but you should be abel to get<br>
> > basic failover bondign working<br>
> > and perhaps tcp loadbalcing provide it does not require switch coperator<br>
> > to work form inside the guest.<br>
> > <br>
> <br>
> What do you mean by not working fully? Are you talking about active-active<br>
> vs active-standby?<br>
some lacp modes require configuration on the swtich others do not<br>
you can only really do that form the pf as at the switch level you can bring down<br>
the port fo ronly some vlans in a failover case.<br>
<br>
<a href="https://docs.rackspace.com/blog/lacp-bonding-and-linux-configuration/" rel="noreferrer" target="_blank">https://docs.rackspace.com/blog/lacp-bonding-and-linux-configuration/</a><br>
<br>
i belive mode 0, 1, 2, 5 and 6 can work withour sepcial switgh config.<br>
<br>
3 and 4 i think reuqired switch cooperation<br>
<br>
IEEE 802.3ad (mode 4) in particalar i think neeed coperation with the switch.<br>
"""The link is set up dynamically between two LACP-supporting peers."""<br>
 <a href="https://en.wikipedia.org/wiki/Link_aggregation" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Link_aggregation</a><br>
<br>
that peerign session can only really run on the PFs<br>
<br>
balance-tlb (5) and balance-alb(6) shoudl work fine for teh VFs in the guest however.<br>
<br>
> <br>
> <br>
> > <br>
> > just keep in mind that by defintion if you decalre a network as on a<br>
> > seperate phsynet to another<br>
> > then you as the operator are asserting that there is no l2 connectivity<br>
> > between those networks.<br>
> > <br>
> > <br>
> This is interesting why not both physnet have the same L2 segment? Are you<br>
> worried STP about the loop? But that is how LACP works both physical<br>
> interfaces on the same segments.<br>
if they are on the same l2 segment then there is no multi tancy when using vlan or flat netowrks.<br>
more on this below.<br>
> <br>
> <br>
> <br>
> > as vlan 100 on physnet_1 is intended ot be a sperate vlan form vlan 100 on<br>
> > phsynet_2<br>
> > <br>
> <br>
> I did a test in the lab with physnet_1 and physnet_2 both on the same VLAN<br>
> ID in the same L2 domain and all works.<br>
<br>
if you create 2 neutron networks <br>
<br>
physnet_1_vlan_100 and physnet_2_vlan_100<br>
<br>
and map phsynet_1 to eth1 and phsnet_2 to eth2<br>
and plug the both into the same TOR with vlan 100 trunked to both<br>
<br>
then boot one vm on physnet_1_vlan_100 and a second on physnet_2_vlan_100<br>
<br>
then a few things will hapen.<br>
<br>
the vms will boot fine and both will get ips.<br>
second there will be no isolation between the two networks<br>
so if you use the same subnet on both then they will be able to direcly ping each other.<br>
<br>
its unsafe to have teant cretable vlan networks in this if you have overlaping vlan ranges between physnet_1 and physnet_2<br>
as there will be no tenant isolation enforeced at teh network level.<br>
<br>
form a neutron point of view physnet_1_vlan_100 and physnet_2_vlan_100 are two entrily differnt netowrks and<br>
its the oeprators responsiblity to ensure there network fabric ensure the same vlan on two phsnets cant comunicate.<br>
<br>
<br>
> <br>
> <br>
> > <br>
> > if you break that and use phsynets to select PFs you are also breaking<br>
> > neutron multi teancy model<br>
> > meaning it is not safy to aloow end uers to create vlan networks and<br>
> > instead you can only use provider created<br>
> > vlan networks.<br>
> > <br>
> <br>
> This is a private cloud and we don't have any multi-tenancy model. We have<br>
> all VLAN base providers and my Datacenter core router is the gateway for<br>
> all my vlans providers.<br>
ack in which case you can live with the fact that there is no mulit taenancy<br>
guarentees because the rules areound phsynets have been broken.<br>
<br>
this is prrety common in telco cloud by the way so you would not be the first to do this.<br>
> <br>
> <br>
> > <br>
> > so what you want to do is proably achiveable but you menthion phsyntes per<br>
> > pf and that sounds like you are breaking<br>
> > the physnets are seperate isolagged phsycial netowrks rule.<br>
> > <br>
> <br>
> I can understand each physnet should be in a different tenant but in my<br>
> case its vlan base provider and not sure what rules it's going to break.<br>
each physnet does not need to be a diffent tenatn<br>
the imporant thing is that neutron expects vlans on differnt physnets to be allcoateable seperatly.<br>
<br>
so the same vlan on 2 phsynets logically represnet 2 differnt networks.<br>
> <br>
> <br>
> > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > On Fri, Mar 10, 2023 at 6:57 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
> > > <br>
> > > > On Thu, 2023-03-09 at 16:43 -0500, Satish Patel wrote:<br>
> > > > > Folks,<br>
> > > > > <br>
> > > > > As you know, SR-IOV doesn't support bonding so the only solution is<br>
> > to<br>
> > > > > implement LACP bonding inside the VM.<br>
> > > > > <br>
> > > > > I did some tests in the lab to create two physnet and map them with<br>
> > two<br>
> > > > > physical nic and create VF and attach them to VM. So far all good<br>
> > but one<br>
> > > > > problem I am seeing is each neutron port I create has an IP address<br>
> > > > > associated and I can use only one IP on bond but that is just a<br>
> > waste of<br>
> > > > IP<br>
> > > > > in the Public IP pool.<br>
> > > > > <br>
> > > > > Are there any way to create sriov port but without IP address?<br>
> > > > techinially we now support adressless port in neutron and nova.<br>
> > > > so that shoudl be possible.<br>
> > > > if you tried to do this with hardware offloaed ovs rather then the<br>
> > > > standard sriov with the sriov<br>
> > > > nic agent you likel will need to also use the allowed_adress_pairs<br>
> > > > extension to ensure that ovs did not<br>
> > > > drop the packets based on the ip adress. if you are using heriarcical<br>
> > port<br>
> > > > binding where you TOR is manged<br>
> > > > by an ml2 driver you might also need the allowed_adress_pairs extension<br>
> > > > with the sriov nic agent to make sure<br>
> > > > the packets are not drop at the swtitch level.<br>
> > > > <br>
> > > > as you likely arlready no we do not support VF bonding in openstack or<br>
> > > > bonded ports in general in then neutron api.<br>
> > > > there was an effort a few years ago to make a bond port extention that<br>
> > > > mirror hwo trunk ports work<br>
> > > > i.e. hanving 2 neutron subport and a bond port that  agreates them but<br>
> > we<br>
> > > > never got that far with<br>
> > > > the design. that would have enabeld boning to be implemtned in diffent<br>
> > ml2<br>
> > > > driver  like ovs/sriov/ovn ectra with<br>
> > > > a consitent/common api.<br>
> > > > <br>
> > > > some people have used mellonox's VF lag functionalty howver that was<br>
> > never<br>
> > > > actully enable propelry in nova/neutron<br>
> > > > so its not officlaly supported upstream but that functional allow you<br>
> > to<br>
> > > > attach only a singel VF to the guest form<br>
> > > > bonded ports on a single card.<br>
> > > > <br>
> > > > there is no supprot in nova/neutron for that offically as i said it<br>
> > just<br>
> > > > happens to work unitnetionally so i would not<br>
> > > > advise that you use it in produciton unless your happy to work though<br>
> > any<br>
> > > > issues you find yourself.<br>
> > > > <br>
> > > > <br>
> > <br>
> > <br>
<br>
</blockquote></div>