Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Management-interface bridge created with wrong MAC on boot, can poison ARP caches #5799

Open
ydirson opened this issue Jul 10, 2024 · 0 comments
Open

Management-interface bridge created with wrong MAC on boot, can poison ARP caches #5799

ydirson opened this issue Jul 10, 2024 · 0 comments

Comments

@ydirson
Copy link
Contributor

ydirson commented Jul 10, 2024

When the MAC address of the management interface changes (we get that when running tests on a nested XCP-ng), there is a timeframe on boot where the bridge configuration uses the old MAC address, eg.:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
	ether 6e:47:08:71:6a:69  txqueuelen 1000  (Ethernet)
	RX packets 0  bytes 0 (0.0 B)
	RX errors 0  dropped 0  overruns 0  frame 0
	TX packets 0  bytes 0 (0.0 B)
	TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
	inet 127.0.0.1  netmask 255.0.0.0
	loop  txqueuelen 1000  (Local Loopback)
	RX packets 16  bytes 1948 (1.9 KiB)
	RX errors 0  dropped 0  overruns 0  frame 0
	TX packets 16  bytes 1948 (1.9 KiB)
	TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
ovs-system: flags=4098<BROADCAST,MULTICAST>  mtu 1500
	ether 8e:e9:50:5c:de:ca  txqueuelen 1000  (Ethernet)
	RX packets 0  bytes 0 (0.0 B)
	RX errors 0  dropped 0  overruns 0  frame 0
	TX packets 0  bytes 0 (0.0 B)
	TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
xenbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
	inet 10.1.6.148  netmask 255.255.0.0  broadcast 10.1.255.255
	ether 06:d0:f7:98:ff:70  txqueuelen 1000  (Ethernet)
	RX packets 0  bytes 0 (0.0 B)
	RX errors 0  dropped 0  overruns 0  frame 0
	TX packets 0  bytes 0 (0.0 B)
	TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

If during that time any network packet is emitted, it uses that now-invalid MAC address, and the peers record it in their ARP tables. They are then unable to send/relay network traffic to that IP address until the ARP entry gets evicted or replaced by a good one.
ydirson added a commit to xcp-ng/xcp-ng-tests that referenced this issue Jul 10, 2024
@ydirson
squash! install 4/n: make sure host appears in PXE ARP tables
cb1f531 
We have to take into account xapi-project/xen-api#5799.
ydirson added a commit to xcp-ng/xcp-ng-tests that referenced this issue Jul 26, 2024
@ydirson
install 4/n: make sure host appears in PXE ARP tables
4d27b64 
Detection of host IP till now relies on the fact we download the
answerfile from PXE server.  Once we take this file from the ISO this
network traffic won't happen so we need some other mechanism to fill the
server's ARP tables.

test-pingpxe.service is installed in install.img by iso-remaster.

Since it is difficult to wait until the IP has been assigned before
launching the service, make it ping continuously until we can reach
the PXE server.

Similarly, once installed the host needs the same mechanism so the test
can find it.  We prepare an installer hook to install the service on the
host, which the generated answerfile will use in later commit.

This also takes into account xapi-project/xen-api#5799: we must avoid
sending out any traffic while the XAPI bridge has an obsolete MAC
attached, or the peer and network equipment in between get confused.

Signed-off-by: Yann Dirson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ydirson