[NETVIRT-127] floating IP NAT default rule sometimes missing when creating a router connected to ext-GW Created: 09/Sep/16  Updated: 20/Sep/16  Resolved: 20/Sep/16

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

Type: Bug
Reporter: Koby Aizer Assignee: Koby Aizer
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: 6677

 Description   

It seems that sometimes when creating a router connected to the external GW, the default rule from 21->26 is not created.

This causes floating IP functionality for this specific router not to work.

In the rules below, you can see that the default rule for vpnId=0x222e0 is missing the default rule. (0x222f0 is a router that was created correctly, and 0x222e2 is the external network vpnId, which shouldn't have this rule):

cookie=0x8000003, duration=244905.117s, table=21, n_packets=22, n_bytes=4622, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.123.2 actions=write_actions(group:150000)
cookie=0x8000003, duration=244904.184s, table=21, n_packets=0, n_bytes=0, priority=42,ip,metadata=0x222e2/0xfffffffe,nw_dst=10.64.101.2 actions=goto_table:44
cookie=0x8000003, duration=244770.584s, table=21, n_packets=66, n_bytes=6300, priority=42,ip,metadata=0x222e2/0xfffffffe,nw_dst=10.64.101.4 actions=goto_table:25
cookie=0x8000003, duration=244768.700s, table=21, n_packets=72, n_bytes=8509, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.123.3 actions=write_actions(group:150001)
cookie=0x8000003, duration=244645.375s, table=21, n_packets=27, n_bytes=2478, priority=42,ip,metadata=0x222e2/0xfffffffe,nw_dst=10.64.101.5 actions=goto_table:25
cookie=0x8000003, duration=244643.131s, table=21, n_packets=33, n_bytes=4687, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.123.4 actions=write_actions(group:150002)
cookie=0x8000003, duration=244367.514s, table=21, n_packets=0, n_bytes=0, priority=42,ip,metadata=0x222e2/0xfffffffe,nw_dst=10.64.101.6 actions=goto_table:44
cookie=0x8000003, duration=244366.054s, table=21, n_packets=0, n_bytes=0, priority=42,ip,metadata=0x222f0/0xfffffffe,nw_dst=1.1.1.2 actions=write_actions(group:150003)
cookie=0x8000003, duration=244347.034s, table=21, n_packets=43, n_bytes=4214, priority=42,ip,metadata=0x222f0/0xfffffffe,nw_dst=1.1.1.6 actions=write_actions(group:150004)
cookie=0x8000003, duration=153501.051s, table=21, n_packets=16, n_bytes=2838, priority=42,ip,metadata=0x222e0/0xfffffffe,nw_dst=10.0.123.5 actions=write_actions(group:150008)
cookie=0x8000004, duration=244367.553s, table=21, n_packets=39, n_bytes=7846, priority=10,ip,metadata=0x222f0/0xfffffffe actions=goto_table:26
cookie=0x8000003, duration=244954.258s, table=21, n_packets=703205, n_bytes=139001718, priority=0 actions=goto_table:80

There are not exceptions seen the log.

Pretty much reproduces for me in a single node environment when running tempest scenario test tempest.scenario.test_minimum_basic.TestMinimumBasicScenario



 Comments   
Comment by Koby Aizer [ 10/Sep/16 ]

This bug seems to happen when you create a router associated with an external network on creation. Devstack & some of the tempest test are configuring it that way.

Comment by Alon Kochba [ 13/Sep/16 ]

https://bugs.opendaylight.org/show_bug.cgi?id=6677

Comment by Alon Kochba [ 13/Sep/16 ]

https://git.opendaylight.org/gerrit/#/c/45457/

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