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.

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

VDE support #5

Closed
brianvanderburg2 opened this issue Aug 30, 2015 · 1 comment
Closed

VDE support #5

brianvanderburg2 opened this issue Aug 30, 2015 · 1 comment
Labels

Comments

@brianvanderburg2
Copy link

I've been playing around with vpcs with GNS3, but also with real router hardware. One scenario I would like to be able to use vpcs to simulate multiple computers to the real hardware. The way I do this is with a "breakout" switch and VLAN. Each VLAN on the host system maps to one port on the switch.

I think this could be done with vpcs tap support as follows:

  • Create a bridge device, move the real NIC to the bridge (eth1)
    • sudo ip link add dev br0 type bridge
    • sudo ip link set dev eth1 master br0
  • enable vlan filtering on the bridge, assign all VLANs used for eth1
    • echo 1 | sudo tee /sys/class/net/br0/bridge/vlan_filteing
    • sudo bridge vlan add dev eth1 vid 10
    • sudo bridge vlan add dev eth1 vid 11
    • sudo bridge vlan add dev eth1 vid 12
  • Run vpcs in tap mode (separate terminals)
    • sudo vpcs -e -i 1 -d pc10
    • sudo vpcs -e -i 1 -d pc11
    • sudo vpcs -e -i 1 -d pc12
  • Move the tap device into the bridge, assign it to the desired VLAN, but without any tagging.
    • sudo bridge vlan add dev pc10 vid 10 pvid untagged
    • sudo bridge vlan add dev pc11 vid 11 pvid untagged
    • sudo bridge vlan add dev pc12 vid 12 pvid untagged

Now, in theory, any traffic sent to/from vpcs would leave the real interface tagged into either VLAN 10, 11, or 12. The associated breakout switch ports can then be connected to the rest of the lab, simulating three different PC connections.

However, that is a lot of work, and a lot of sudo. Currently my typical setup is, for every NIC device I have a matching bridge device and a matching VDE switch. I then place the NIC and the VDE tap interface into the bridge. This is a dumb bridge and just passes the frames directly without any VLAN filtering. VDE supports loading a configuration file and assigning VLANs to specific "ports" that a VDE client connects to. It would be nice if VPCS would also have a VDE mode, which would accept a control file for VDE, and a port number or more. In addition, the port number should be able to be changed from the CLI of VPCS:

  • vpcs -i 10 --vde /var/run/vde2_gns.ctl/ctl --port 0 (Sets all initial connections to VDE port 0)
  • 1> port 5 (change VPC 1 to use VDE port 5)
  • 2> port 6 (change VPC 2 to use VDE port 6)
  • 3> port 7 (change VPC 3 to use VDE port 7)
  • 4> port 7 (change VPC 4 to use VDE port 7, I'm pretty sure VDE allows multiple connections to the same port to duplicate settings, so ideally VPCS could support it as well)

Several advantages of this over the bridge, at least in my opinion:

  • VDE can be configured to allow specific groups of users to connect via the permissions on the control file/directory, where changing the tap interface master and VLANs requires root/sudo. In addition, individual ports can be configured to require specific users.
  • The VDE approach can work without VLAN filtering commands and without any need to create VLAN sub-interfaces bridging them to the tap interfaces.
  • A single command can be used to automatically connect to all the correct ports, something like:
    • vpcs -i 10 --vde /var/run/vde2_gns.ctl/ctl --port 4,5,6,7,8,9,10,11,12,13
  • No sudo is needed. Once the VDE switch is configured correctly (as administrator via a startup file like /etc/network/interfaces), Any user in the correct group can access the VDE switch. Such a VDE configuration may look like, allowing any user who connects to port 10, 11, or 12 in VDE to be VLAN 10, 11, or 12 on the breakout swtich.
    • vlan/create 10
    • vlan/create 11
    • vlan/create 12
    • vlan/addport 10 1
    • vlan/addport 11 1
    • vlan/addport 12 1
    • port/create 10
    • port/create 11
    • port/create 12
    • port/setvlan 10 10
    • port/setvlan 11 11
    • port/setvlan 12 12
@grossmj grossmj added the wontfix label Mar 5, 2019
@grossmj
Copy link
Member

grossmj commented Mar 5, 2019

Sorry, we won't add any new feature in VPCS.

@grossmj grossmj closed this as completed Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants