Manuel,
Might be a dumb question, but are you making sure no OVS instances connect to 
ODL until netvirt is fully up (aka can curl 
restconf/operational/network-topology:network-topology/topology/netvirt:1) and 
the tables have been offset?  Seems like this could be a timing problem there.

Tim Rozet
Red Hat SDN Team

----- Original Message -----
From: "Srikanth Lingala" <[email protected]>
To: "Manuel Buil" <[email protected]>, [email protected], "Brady 
Allen Johnson" <[email protected]>, "Sam Hague" 
<[email protected]>
Cc: [email protected], [email protected]
Sent: Monday, March 6, 2017 1:12:38 PM
Subject: Re: [opnfv-tech-discuss] [sfc-dev] [odl-sfc] Bug in OPNFV-SFC test     
cases

Hi,
Sometimes, I also encountered the same problem. I think some issue is there in 
the ODL. I am using OPNFV Colorado 3.0.
VM's will not get IP address from Neutron DHCP agent.
To fix the issue, I needed to do the following:

ovs-vsctl del-br br-int
ovs-vsctl del-manager
service neutron-server restart
service opendaylight restart
ovs-vsctl set-manager tcp:<ODL_IP>:6640

Sometimes, SFC tables are adding from table id's 11, but not table id 151. 
After restarting ODL, that issue fixed for me.

Regards,
Srikanth.


-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Manuel Buil
Sent: Monday, March 06, 2017 11:12 PM
To: [email protected]; Brady Allen Johnson 
<[email protected]>; Sam Hague <[email protected]>
Cc: [email protected]; [email protected]
Subject: [sfc-dev] [odl-sfc] Bug in OPNFV-SFC test cases

Hello guys,

We moved to ODL Boron SR2 lately and the most basic OPNFV test cases are 
failing because VMs don't get an IP lease from the DHCP server. When checking 
the tables of the compute nodes, they seem a bit messy to me and it looks like 
that perhaps a patch might have broken the compatibility with the way we are 
currently separating tables between SFC and Netvirt until SFC is integrated 
with Genius (remember we are configuring the variables: table-offset:1 and 
sfc-of-table-offset:150, sfc-of-app-egress-table-offset:11).

Here are the flows:

http://pastebin.com/Bii0vaNC

As you can see, all packets are dropped in table 110 (those are DHCP packets). 
There are strange things like for example: there is no way to reach table=1, 
table=21, table=41,etc. Exactly the tables which are needed and modified by the 
configuration of the offset +1, that's why I suspect that there was a patch in 
netvirt which might have not taken this offset into account.

Do you agree that the tables are wrong? Any idea what can be causing that flow 
configuration?

Thanks,
Manuel



_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

Reply via email to