[BUG] Connectivity issues in sample1.imn in clean Ubuntu 20.04 VM install

[Kribylet]

Describe the bug
There is only partial network connectivity in the sample1.imn example network when running it in a Ubuntu 20.04 VM. In particular, there seems to be no connection between node n5 and n15.

To Reproduce
Steps to reproduce the behavior:

1. Install Ubuntu 20.04 using latest VirtualBox and ubuntu-20.04.3-desktop-amd64.iso (with 3rd party software).
2. From a terminal, run:

sudo apt-get install -y gawk autoconf automake libtk-img openssh-client openssh-server ebtables git
sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy
git clone https://github.com/coreemu/core.git
cd core
# Proposed fix from issue #596
sed -i 's/pipx install poetry/pipx install poetry==1.1.7/' tasks.py
#
./bootstrap.sh
./install.sh
/sudo core-daemon

3. From another terminal, start core-gui
4. Open sample1.imn
5. Press start
6. Pause mobility script and move node n7 into range of node n5.
7. Wait a while and then try to ping 10.0.0.7 from node n11.

Expected behavior
Ping response from n7 received at node n11.

Screenshots

Desktop (please complete the following information):

• OS: Linux Mint 20.2 hosting Ubuntu 20.04
• CORE Version 7.5.1
• EMANE Version N/A

Additional context
I have little prior experience with CORE so this could very well be a configuration issue on my part rather than a bug, but there is no generic issue template.

[dpemmerich]

FWIW, I am seeing the same thing on Ubuntu 20 VM running in VMWare.
I'm new to core, but it appears to me that n5 is not distributing the routes to n15. The connectivity is there, as I can ping from n15 to n5 (10.0.6.2).

Uncommenting the ospf lines

interface eth1
  ip address 10.0.6.2/24
  !ip ospf hello-interfal 2
  !ip ospf dead-interval 6
  !ip ospf retransmit-interval 5
  !ip ospf network point-to-point
  ipv6 address a:6::2/64

in the Zebra config for node n5 seems to work. Not sure if that would be the intended fix, but it's working consistently when I reload, uncomment, start..... repeat

[Kribylet]

Documentation related to a project using CORE that I am working with implies that sample1.imn has worked at some point during 2020; sample1.imn was last modified 5 years ago. This leads me to believe that the issue lies elsewhere.

I've tried examining earlier commits to see if the issue was introduced in a particular commit. I wasn't able to find a working commit prior to the introduction of poetry after which point bisection became more complicated.

Does anyone know of a configuration under which sample1.imn runs with full connectivity (outside VM, using a different virtualization tool or operating system image)?

[bharnden]

For the most part CORE will orchestrate the network and that should not have changed and wouldn't have active impact at run time, beyond a more obvious failure.

It is possibly related to the software routing traffic, OSPF MDR, which has been updated over time and could be related.

[bharnden]

Taking a look into this, it seems it may likely be related to how old that scenario is and updates to OSPF MDR. I will try to double check using a much older OSPF MDR version to validate.

But the scenario has a hard coded configuration for the zebra service on n5.

1. Right click on n5
2. Click "Services"
3. Click the wrench icon next to "zebra"
4. Click "Defaults"
5. Click "Apply"
6. Click "Apply"

This should clear out the hard coded configuration, which would achieve similar to what @dpemmerich noted above and worked for me.

[bharnden]

Trying out older version of OPSF MDR didn't prove out any success, but the scenario file itself hasn't changed in 5 years. I don't know for sure if it ever worked as you expect. It was created before my time and was meant to serve as a notional example, from what I know.

[Kribylet]

I have this image capture of the desired behavior, ostensibly dated back to 20160930 judging by the core install files (pulled from subversion!). The surrounding documentation implies that no additional configuration was required after install on a Ubuntu 16.04 VM and that this behavior was indicative of a working CORE install. Unfortunately I cannot speak to when this behavior was last seen, so at best this timestamps the behavior to being in place roughly at the time of the last change to the sample1.imn file. At the very least it shows that the behavior was there and has changed.

CORE as configured above appears to run the project specific tests we have successfully, so it seems that CORE behaves properly otherwise.

[bharnden]

Hard to say, as far as the git repo goes, the file seems to have always had this configuration, since the initial commit. A picture alone doesn't really tell the whole story either, it is possible things could have been further tweaked at the time.

It is possible with a much older OSPF MDR build at that time, which can run on Ubuntu 16, things worked.

Seems like the current plan would be to remove the custom configuration and let the default service behavior take place, which would allow a working scenario.

[Kribylet]

That seems sensible. As a topic for a separate issue, it may be appropriate for CORE to specify the intended behavior of included scenarios in its documentation so that the intended behavior is clear. This particular issue was raised due to third-party documentation that as you mention was not robust enough to definitively show whether there has been a change in the behavior of CORE. If the intended behavior is clearly specified it could help both highlight unexpected behavior changes in the future and provide a single source of truth regarding what should be expected of a working installation of CORE.

[bharnden]

The samle1.imn file has been cleaned up on the develop branch and removes the service customization causing problems.

The people who created the original examples are not present, so getting the insight you desire is not possible. We can either leave them as is, or remove them, if we mandated they needed to have one.