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

Deal with moving MACs - #2437

Open
rade wants to merge 6 commits into
1.7from
2436-mac-move
Open

Deal with moving MACs#2437
rade wants to merge 6 commits into
1.7from
2436-mac-move

Conversation

@rade

@rade rade commented Jul 10, 2016

Copy link
Copy Markdown
Member

Fixes #2436

@rade

rade commented Jul 10, 2016

Copy link
Copy Markdown
Member Author

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
Comment thread router/network_router.go
router.Overlay.(NetworkOverlay).InvalidateRoutes()
}
}

This comment was marked as abuse.

@brb
brb force-pushed the 2436-mac-move branch from 2f6b843 to 9de9ae9 Compare July 25, 2016 12:38
@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

awh commented Aug 10, 2016

Copy link
Copy Markdown
Contributor

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

@brb

brb commented Aug 10, 2016

Copy link
Copy Markdown
Contributor

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

awh commented Sep 21, 2016

Copy link
Copy Markdown
Contributor

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
Copy Markdown
Contributor

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

@brb

brb commented Jun 5, 2018

Copy link
Copy Markdown
Contributor

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

iExalt commented Mar 5, 2020

Copy link
Copy Markdown

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

@bboreham

bboreham commented Mar 6, 2020

Copy link
Copy Markdown
Contributor

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