Skip to content

makes miniNExT compatible to mininet 2.3.0 #15

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.

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

Open
wants to merge 4 commits into
base: 1.4.0
Choose a base branch
from

Conversation

arthur00
Copy link

This patches miniNExT to be compatible with current master branch of mininet.

  • Fixes issue with console (mininet now uses openpty)
  • Few non-functional changes to match current mininet API
  • The way interfaces are created in namespaces changed in current mininet. There is now a 'fast' option, that creates the interface with 'namens' as a parameter of 'ip'. The problem with using it on miniNExT is that hosts are now in different PID namespaces, so when trying to bring up the interface pair (e.g. a1-eth0 and s1-eth1), the switch (s1) does not see the host (a1) PID, and fails. This was fixed simply by creating links with the fast=False option, which now creates the interface in universal namespace, and only then moves it to the specified namespace.

@arthur00
Copy link
Author

This patch worked on the mininet vm, but is failing on Ubuntu 16.10, so it needs more work, but its a start. Feel free to put it in a branch or reject it if you wish, I will keep trying to get it to work but its starting to be more effort than its worth :)

Copy link
Member

@bschlinker bschlinker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great -- thanks for working on this! I have a few quick comments.

Given that MiniNExT currently doesn't work on 16.10, I'm guessing there's no regression in accepting your patch. Let me know if you're aware of one (e.g., will MiniNExT no longer work with 16.04? what Ubuntu version does the VM currently use?)

@@ -74,4 +72,4 @@ def __init__(self):
nodeConfig=quaggaSvcConfig)

# Attach the quaggaContainer to the IXP Fabric Switch
self.addLink(quaggaContainer, ixpfabric)
self.addLink(quaggaContainer, ixpfabric, fast=False)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for providing an explanation of this change in the PR -- can you add a brief comment to the file as well?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

# If this node has a private PID space, grab the PID to attach to
# Otherwise, we use the same PID as the shell's PID
if self.inPIDNamespace:
# monitor() will grab shell's true PID and put in self.lastPid
self.monitor()
self.monitor(1000)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reasonable to have a timeout -- not sure if Mininet had this support before, but certainly better than hanging.

mininext/node.py Outdated
self.pollOut.poll()
self.waiting = False
self.cmd( 'stty -echo' )
self.cmd( 'set +m' )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it is currently the following in mininet:

        # +m: disable job control notification
        self.cmd( 'unset HISTFILE; stty -echo; set +m' )

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

mininext/topo.py Outdated
"""Adds a host using the MiniNExT host constructor.
name: host name
cls: host constructor
opts: host options
returns: host name"""
if not opts and self.hopts:
opts = self.hopts
return BaseTopo.addNode(self, name, cls=cls, **opts)
opts['cls'] = Host
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The disadvantage of this is that it prevents further extensibility -- if you call addHost('name', cls=NextGenHost, NextGenHost will be overridden by Host. Can you either check if cls is set and not override, or just leave it in the constructor?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! I like checking for cls instead, because this function is meant to override another, so I'd prefer to have the signatures of the methods matching to avoid confusion. Not adamant about it though.

mininext/node.py Outdated
cmd = [ 'mxexec', opts, 'env', 'PS1=' + chr( 127 ),
'bash', '--norc', '-is', 'mininet:' + self.name ]
master, slave = pty.openpty()
self.shell = Popen(cmd, stdin=slave, stdout=slave, stderr=slave,
close_fds=True)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like close_fds=False now in mininet -- should it be updated here as well?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@arthur00
Copy link
Author

The mininet vm comes with an Ubuntu 14.04, and I installed whatever quagga was available to that ubuntu version. Upon changing to 16.10 some things broke, so I've chosen to go another path for now - I'm starting bgpd and zebra directly on the topology bring-up script and passing the conf files as parameters. That seems to work, but I haven't tested yet.

I figured I'd leave these changes here in case anyone feels this direction is worth pursuing. But ,as mentioned before, it still seems to give me trouble in newer distros (probably because of quagga)

@lifeoftomi
Copy link

Hi @arthur00 and @bschlinker, is compatibility with Mininet 2.3.0 still possible?

@arthur00
Copy link
Author

Hi @arthur00 and @bschlinker, is compatibility with Mininet 2.3.0 still possible?

I haven't touched mininet in 4 years, so I have no idea what the status of things are anymore.. My branch seems to still be open, so I guess it still could be merged.. It will be difficult for me to support this as I have little recollection of the work I did for this PR back then.

@lifeoftomi
Copy link

Thanks @arthur00 👍

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

Successfully merging this pull request may close these issues.

3 participants