On Thu, Jul 5, 2018 at 3:15 PM, Daniel Alvarez wrote:
>
>
> On 5 Jul 2018, at 23:34, Han Zhou wrote:
>
>
>
> On Thu, Jul 5, 2018 at 6:00 AM, Daniel Alvarez Sanchez <
> dalva...@redhat.com> wrote:
> >
> > Hi Han, all
> >
> > While implementing Port Groups in OpenStack I have noticed that we are
> On 5 Jul 2018, at 23:34, Han Zhou wrote:
>
>
>
> On Thu, Jul 5, 2018 at 6:00 AM, Daniel Alvarez Sanchez
> wrote:
> >
> > Hi Han, all
> >
> > While implementing Port Groups in OpenStack I have noticed that we are
> > duplicating the lflows for the DHCP now with the current code. Seeking
On Thu, Jul 5, 2018 at 6:00 AM, Daniel Alvarez Sanchez
wrote:
>
> Hi Han, all
>
> While implementing Port Groups in OpenStack I have noticed that we are
duplicating the lflows for the DHCP now with the current code. Seeking for
advice here:
>
> When we create a Neutron subnet, I'm creating a Port
Ok, I agree. We don't want to change a hash function but only the input to
it, i.e., we want that hash will be computed based only on label number in
our case in microflow cache. Of course for such the hash the label number
can be used itself as a hash value.
Regarding proposed mechanism, let say
On Thu, Jul 05, 2018 at 12:02:31PM +, Vishal Deep Ajmera wrote:
> Hi,
>
>
>
> The udpif_revalidator function uses dump-duration time to determine the flow
> limit and tunes it as per system conditions for e.g. if duration is more,
> flow limit is reduced and vice-versa. However I notice
This clearly can’t be the case as that could lead to Exact Match Cache overflow
caused by malicious attacker generating millions of frames each with a unique 5
tuple.
Or is it?
adam
netconsultings.com
::carrier-class solutions for the telecommunications industry::
From:
Typically, changing a hash function in this way will only increase the
number of hash collisions without reducing the number of hash table
entries.
On Thu, Jul 05, 2018 at 10:49:03PM +0200, Grzegorz wrote:
> Sure, but we want to examine how a number of flows is reduced when proposed
> mechanism
Sure, but we want to examine how a number of flows is reduced when proposed
mechanism is implemented. If we use what is now available in ovs, it will
still generate thousands of flows (hashes) in Exact Match Cache. Please
correct me if I'm wrong
czw., 5 lip 2018 o 22:41 Ben Pfaff napisał(a):
>
You can match on MPLS flows without needing to modify OVS's kernel flow
table structure. Why do you want to modify it?
On Thu, Jul 05, 2018 at 09:25:05PM +0200, Grzegorz wrote:
> The goal is to minimize number of flows (aggregate them) in the core of
> network using some labeling. In our case
The goal is to minimize number of flows (aggregate them) in the core of
network using some labeling. In our case MPLS is proposed but any other
technique allowing for labeling may be used, e.g. VLANs. This is part of s
bigger idea. Details are presented in paper
It's an odd change. What's the goal?
On Thu, Jul 05, 2018 at 08:27:08PM +0200, Grzegorz wrote:
> I'm taking about hash based on which flow table is looked up in kernel data
> path.
>
> czw., 5 lip 2018 o 20:20 Ben Pfaff napisał(a):
>
> > Which hash are you talking about? OVS has lots of
I'm taking about hash based on which flow table is looked up in kernel data
path.
czw., 5 lip 2018 o 20:20 Ben Pfaff napisał(a):
> Which hash are you talking about? OVS has lots of hashes all over.
>
> On Thu, Jul 05, 2018 at 07:46:57PM +0200, Grzegorz wrote:
> > Hi Ben,
> > You're absolutely
Which hash are you talking about? OVS has lots of hashes all over.
On Thu, Jul 05, 2018 at 07:46:57PM +0200, Grzegorz wrote:
> Hi Ben,
> You're absolutely right. Thank you! Now I understand how it works.
>
> So having such the knowledge I have another question. In order to implement
> other
Hi Ben,
You're absolutely right. Thank you! Now I understand how it works.
So having such the knowledge I have another question. In order to implement
other part of our mechanism I need to place in kernel space only flows that
for which mach (hash) is done based only on MPLS label. If I correct
Hi,
We want to make some OSV code modification in order to obtain fuctionality
desribed in https://arxiv.org/pdf/1805.07993.pdf
Strictly speaking wa want to implement the part related to Figure 4 on page
10. In shortcut, the proposed mechanism uses 2 flow tables (Detailed and
Coarse Flow Table,
It turns out that the file /etc/init.d/openvswitch-switch has one of the
lines you mentioned, but not the other. When I added the one line it
worked.
_SYSTEMCTL_SKIP_REDIRECT=yes # this line was present
SYSTEMCTL_SKIP_REDIRECT=yes # missing this line
I added the second line and it boots now
>
>
> So, if I build OVS from source, am I going to have the same problem? It
> seems that everything in Squeeze is systemd? I guess I could try and
> see. Will the init.d script work?
>
>
You said it is OVS 2.6.2. First thing to do is to simply modify your
/etc/init.d/openvswitch-switch to
Hi Han, all
While implementing Port Groups in OpenStack I have noticed that we are
duplicating the lflows for the DHCP now with the current code. Seeking for
advice here:
When we create a Neutron subnet, I'm creating a Port Group with the ACL for
the DHCP:
_uuid :
Hi,
The udpif_revalidator function uses dump-duration time to determine the flow
limit and tunes it as per system conditions for e.g. if duration is more, flow
limit is reduced and vice-versa. However I notice one issue with the logic used
in the implementation:
if (duration >
19 matches
Mail list logo
