[NETVIRT-385] SD-VPN:L3 service: performance issue: takes ~5sec in a simple scenario with 1CPE for the ODL to update the new rules (new learned mac) on the OVS Created: 21/Dec/16  Updated: 19/Oct/17  Resolved: 13/Mar/17

Status: Resolved
Project: netvirt
Component/s: General
Affects Version/s: Boron
Fix Version/s: None

Type: Bug
Reporter: Gal Gabi Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 7418

 Description   

add a tenant with a L3 service
1 CPE with 2 UNIs
send traffic between the ports

performance issue:
depends on the host (server) - can take ~5sec for the ODL to update the rules on the OVS

example:
send 1packet from host behind c1u1 to host behind c1u2 - this packet will fail since the mac of host c1u2 is not learned yet
need to sleep ~5sec before sending the same traffic again in order for it to pass.
even though arp reply was sent from host behind c1u2 after the 1packet that was sent - i understood from Alex that it takes time for the ODL to update the OVS with the new rules

in the demo server needed to wait 5 sec in other servers (dl-380) sometimes 3sec are enough



 Comments   
Comment by Gal Gabi [ 21/Dec/16 ]

performed another scenario:
4 CPEs with 2 UNIs in each
sent 1 packet from host behind c1u1 to an host behind all other ports - meaning:
c1u1 --> c1u2
c1u1 --> c2u1
c1u1 --> c2u2
c1u1 --> c3u1
c1u1 --> c3u2
c1u1 --> c4u1
c1u1 --> c4u2
of course all will fail the 1st time

at this point i entered a sleep of 7 sec before running the same traffic again
not all traffic passed

when i waited 10 sec - all traffic passed
i am using an hp (hp-81) server as the host

Comment by Gal Gabi [ 28/Dec/16 ]

in a scenario with 4 CPEs, on each UNI 2 sub interfaces
needed to sleep for 15-20 sec before sending the traffic

Comment by Koby Aizer [ 13/Mar/17 ]

Review: https://git.opendaylight.org/gerrit/#/c/51968

Generated at Wed Feb 07 20:21:26 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.