Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Deal with moving MACs #2437

Open
wants to merge 6 commits into
base: 1.7
Choose a base branch
from
Open

Deal with moving MACs #2437

wants to merge 6 commits into from

Conversation

rade
Copy link
Member

@rade rade commented Jul 10, 2016

Fixes #2436

@rade
Copy link
Member Author

rade commented Jul 10, 2016

Things left to do:

  • make it work - see networking broken for containers with moved MAC #2436 (comment) onwards
  • convince ourselves that we aren't introducing any packet loops
  • refactor to get rid of MacCache.Add and rename MacCache.AddForced to MacCache.Add
  • refactor to extract the common MacCache interaction and conflict handling in NetworkRouter.handleCapturedPacket and NetworkRouter.handleForwardPacket
  • add a test, covering both sleeve and fastdp mode

@rade rade added this to the 1.6.1 milestone Jul 20, 2016
router.Overlay.(NetworkOverlay).InvalidateRoutes()
}
}

This comment was marked as abuse.

@brb brb self-assigned this Jul 28, 2016
@brb brb changed the title [WIP] deal with moving MACs Deal with moving MACs Jul 28, 2016
@awh
Copy link
Contributor

awh commented Aug 10, 2016

@brb did you mean for this to still be assigned to you?

@brb
Copy link
Contributor

brb commented Aug 10, 2016

Yep, as I haven't convinced myself that we do not introduce loops.

@brb brb modified the milestones: 1.6.1, 1.6.2 Aug 18, 2016
@awh awh modified the milestones: 1.6.2, 1.7.1 Sep 21, 2016
@awh
Copy link
Contributor

awh commented Sep 21, 2016

Needs rebasing on 1.7 after the 1.7.0 release.

@awh awh modified the milestones: 1.7.1, 1.7.2, 1.7.3 Oct 5, 2016
@brb brb changed the base branch from 1.6 to 1.7 October 19, 2016 16:35
otherwise NetworkRouter.handleForwardedPacket fails to clear out the
now invalid flows.
rade and others added 5 commits October 19, 2016 17:35
We see such packets when a MAC that we previously saw at a remote peer
has been moved to ours. Dropping these packets cuts off network
connectivity for the new owner of the MAC.

Instead we update the MAC cache and flush the flows, to remove the now
incorrect entries for that MAC. And carry on as normal.
The absence of the deletion might lead to installation of invalid
flows, because the fastdp bridge MAC cache can have stale entries
which are used when deciding when/what flows to create.
The former function is obsolete.
The function updates the MAC cache and invalidates routes if needed.
@awh awh modified the milestones: 1.7.3, 1.8.1 Nov 4, 2016
@bboreham bboreham modified the milestones: 1.8.2, 1.8.1 Nov 21, 2016
@brb brb modified the milestones: 1.8.2, 1.8.3 Dec 8, 2016
@bboreham bboreham modified the milestones: overflow, 1.8.3 Feb 2, 2017
@bboreham
Copy link
Contributor

Coming up on two years: what should we do with this?

@brb
Copy link
Contributor

brb commented Jun 5, 2018

I'd prefer to bring this PR to life. First I'd need to refresh context though. Perhaps, it could happen when working on #2877

@iExalt
Copy link

iExalt commented Mar 5, 2020

Any word on this PR/associated issue #2877? I have a use case where moving MACs is intentional and not an error. @brb

@bboreham
Copy link
Contributor

bboreham commented Mar 6, 2020

Martynas moved to another company so probably isn't going to resurrect this PR.
It is expected to be difficult to understand all the ramifications of the change, and to test them.

#2877 is not really related, except they both touch the same code. This PR targets #2436.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants