Three Secrets Of VIRL

Networking
Ralph Schmieder, Technical Leader DevNet
Three Secrets Of VIRL Networking
“Like all powerful tools, VIRL (Virtual Internet Routing Lab) confers greatness on
those who learn its secrets“
This session focuses on the secrets of VIRL's networking fundamentals.
• Do you want to extend a virtual network?
• Connect VIRL to external networks and devices?
• Connect to virtual machines over the Internet?
• Connect to real devices in another location?

3
Topics Covered
Practical solutions to these questions and more will be provided in an exciting 90
minutes with the following agenda:
• VIRL Networking Fundamentals
• How to access the Internet from within VIRL
• Hybrid networks: Virtual and Real devices
• Leverage VPNs: The Combo -- combine it all!
Attendees will receive a 'cookbook' slide deck with expansive material on each
topic.

4
High Level Agenda
1. VIRL Networking Fundamentals – The baseline.
Dummies, IP tables, NAT and Neutron Networks
2. Accessing the Internet and External Networks
Hybrid Networks: Real and virtual Devices
3. Need more? How is it tied together?
External Networks / Adding / Deleting / Modifying
flatter.sh https://github.com/VIRL-Open/virl-utils
4. Leverage VPNs

5
Three Secrets Of VIRL
Networking
Ralph Schmieder, Technical Leader DevNet
Session Objectives
After this session, you should be able to
• Better understand VIRL Networking
• Leverage Trunking with VIRL
• Optimize VPN use with VIRL
• Extend your topologies remotely

7
Agenda
• (Short) Introduction to VIRL
• VIRL Networking Fundamentals
• Secret #1: Trunking
• Secret #2: OpenVPN without Limits
• Secret #3: The ‘Combo’
• Conclusion

• Addendum 1: VMware Workstation / Fusion

• Addendum 2: Advanced Simulation Controls
(Short) Introduction to
VIRL

9
The Challenge
DevOps and NetOps have a compelling need to:
• Create new network applications and solutions
• Learn and test new features and facilities
• Innovate to solve business problems
To do this they need a test-bed that is:
• Easy to build • Easy to access
• Easy to configure • Portable
• Easy to scale • Inexpensive

And everyone wants their own…

10
What is VIRL?
A network orchestration and virtualization platform that enables:
• Point-and-click network design
• Automated configuration creation
• Integration VM’s running platform-sync’d code
• Rapid setup and tear-down
• Seamless connectivity with ‘real’ networks
• Portability and repeatability

11
 VIRL Architecture
Virtualized Platform Operating Systems

IOS XR NX-OS IOS XE IOS Servers

Virtualized Virtualized Virtualized in Virtualized Ubuntu, Cirros,

in in NX-OSv CSR1000v in IOSv and 3rd party Virtual
IOS XRv IOSvL2 Machines

Virtual Machines run the operating system but are NOT representations of a
particular hardware platform – no fans, no switch fabric, no ASIC models 12
 VIRL Architecture
Virtualized Platform Operating Systems

IOS XR NX-OS IOS XE IOS Servers

Virtualized Virtualized Virtualized in Virtualized Ubuntu, Cirros,

in in NX-OSv CSR1000v in IOSv and 3rd party Virtual
IOS XRv IOSvL2 Machines

 Same Control-plane code  Different CPU performance

 Same Management plane code  Different Forwarding plane code
 Same memory footprint  No ASIC emulation 13
Built on OpenStack Kilo

Horizon (Dashboard)
Cinder
Swift
Nova (Block Neutron
(Object
APIs / CLI

(Compute Services) Storage (Networking Services)

Services)
Services)

Keystone (Identity Services)

Glance (Image / Repository Services)

IaaS / cloud orchestration software – creates, manages, and deletes virtual

resources according to API- or CLI-based instructions
14
VIRL System Stack

15
VIRL System Stack

libvirt / KVM

Simulation(s)

15
VIRL System Stack

OpenStack Kilo

libvirt / KVM

Simulation(s)

15
VIRL System Stack

VIRL (STD / UWM)

OpenStack Kilo

libvirt / KVM

Simulation(s)

15
VIRL System Stack

Linux Ubuntu 14.04

VIRL (STD / UWM)

OpenStack Kilo

libvirt / KVM

Simulation(s)

15
VIRL System Stack

or Bare Metal
Outer Hypervisor

Linux Ubuntu 14.04

VIRL (STD / UWM)

OpenStack Kilo

libvirt / KVM

Simulation(s)

15
VIRL System Stack
Bare metal System
or Bare Metal
Outer Hypervisor

Linux Ubuntu 14.04

VIRL (STD / UWM)

OpenStack Kilo

libvirt / KVM

Simulation(s)

15
VIRL System Stack
Bare metal System
UCS or Bare Metal
Outer Hypervisor
VMware vSphere
Linux Ubuntu 14.04
CLI, Salt, …
VIRL (STD / UWM)
APIs

STD, UWM OpenStack Kilo

Nova, Neutron, … libvirt / KVM

libvirt

device specific, RESTCONF, …) Simulation(s)

15
VIRL System Stack

Linux Ubuntu 14.04 Today, we’re

VIRL (STD / UWM) focusing here
OpenStack Kilo

15
VIRL Networking
Fundamentals

24
Motivation
• External connectivity and accessibility is key
• IP addresses, routing, Firewalling, NAT…
• Ability to extend to incorporate real devices
• Needs planning
• How will VIRL fit into your network?

Need to understand the terminology

and internal VIRL networking

25
Terminology
• VIRL Host: Machine that runs simulations. Can
be a VM itself
• VIRL Node: VM running on VIRL Host. Can be
a router, switch, server, appliance, …
• Topology: Simulated Network with multiple
VIRL Nodes running on a VIRL Host. Multiple
running topologies on single VIRL Host possible
• VIRL Networks: Virtual Networks within VIRL
Host connecting VIRL Nodes within a topology
and to outside world

26
NICs on a VIRL Host
By default: Five NICs on each VIRL Host
• MGMT: Mandatory. Management access via this
interface
• FLAT and FLAT1: Optional. Full, Layer-2
bi-directional connectivity for all VIRL Nodes
connected to the FLAT and the FLAT1 network
segment
• SNAT*: Optional. One-way Layer-3 access to
external networks. VIRL Nodes with specific SNAT
connector are externally exposed
• Cluster Control: Optional. Needed for clustering
VIRL hosts (future)
27

*SNAT = Static NAT

NICs on a VIRL Host

Control
• System Control Plane Interfaces (Management
of some sorts)
• Simulation Data Plane Interfaces
(Network simulation traffic)
Data

Control

28
 Management
Connectivity Options

29
VIRL Node OOB Management Options
• All nodes in a simulations connect to the Management Network with first
interface (usually Gi0/0)
• Jumphost - Linux Container or VM?
• Where is Gi0/0 connected?
1. Private (per) project network
2. Private (per) simulation network
3. Shared FLAT network
4. <not specified> == option 1
• Configured ‘per Topology’
• If set to ‘Shared flat network’ it defaults to FLAT - Can be set to FLAT1 with per-
topology extension AV pair
30
ANK: Infrastructure Only
• Per topology setting

VM Maestro
• Creates minimum configuration for
OOB management mechanics
• Make sure that
• Management access (SSH, Telnet)
• Configuration extraction
• Live Vis

Web Editor
do work

31
Private Simulation vs. Private Project
Simulation
• Per-simulation OOB Management
Network (10.255.0.0/16)
• Per-simulation Jumphost (LXC or
VM) provides access point into the
OOB network from the outside world
• NO outside access via OpenStack
router
Project
• Single OOB Management shared
across all simulations of the same
project
• Typically, project == user
• But: Projects can have multiple users
• One shared Jumphost (LXC or VM)
for all simulations of a project provides
access point into the OOB network
from the outside world
• Outside access via OpenStack router
32
Jumphost – LXC or VM
• Helps to access the OOB Management Network
• Facilitator between simulations and outside world
• One interface on FLAT, one interface on OOB network
• SSH port exposed on MGMT interface
• Two variants: VM (Ubuntu Linux, shared) and Linux Container (LXC, per simulation)
• LXC – lightweight, cut-down Linux instance
• VM – heavyweight, full-feature Linux instance

• Jumphost
• Provides port forwarding of SSH on the VIRL host
• Direct access to router VTY via VM Maestro

33
LXC Jumphost (cont.)
• Exposed port on VIRL Host displayed in VM Maestro UI
• With given example on right:
• Use ssh –p 41399 virl@ip-of-virl-host
to access it directly
• When SSH option is provided for VMs, access to VM
possible via the Jumphost
• Example
host:~ user$ ssh -p 41399 guest@172.16.1.1
guest@172.16.1.1's password:
guest@mgmt-5dZh7N$ telnet 10.255.0.2
Trying 10.255.0.2...
Connected to 10.255.0.2.
Escape character is '^]'.
**** BANNER ****
Password:

34
Four Simulations: Per Project and Per Simulation
Gateway to
the outside
LXC

LXC
LXC Jumphosts
‘invisible’ to
Openstack –
VIRL controlled!
Neutron
OpenStack
Two ‘Per
Router
Simulation’ Two ‘Per One
Topologies Project’ Jumphost for
with one IOSv Topologies ‘Per Project’
node each with one IOSv Simulations
node each (either LXC
Same IPv4 Network, all different L2 segments (‘cables’) or HVM) 35
OOB: Access via FLAT
• Set to ‘Shared FLAT Network’ VIRL Host
• All VIRL Nodes connected to FLAT
or FLAT1 segment
FLAT 172.16.1.0/24

• With first Interface (Gi0/0) .61

Gi0/0
.60
• Addresses dynamically assigned
• ‘Bridged’ to Outside via FLAT or
FLAT1 NIC .62

• Full Outside Exposure (Security!)

36
OOB: Access via Private networks
• Set to ‘Private project network’ VIRL Host
OpenStack Neutron Router
• All VIRL Nodes connected to OOB for user ‘Guest’
.53 .1
segment with first interface
SNAT 172.16.3.0/24 10.255.0.0/16

• Addresses dynamic by VIRL

• ‘Routed’ to Outside via OpenStack
router and SNAT NIC .11

Gi0/0
• Default route on IOSv has to be set .10
to manually (10.255.0.1)
• VIRL Nodes not exposed to Outside .12

37
Data Plane: SNAT Connector Example
VIRL Host
OpenStack Neutron Router
for user ‘Guest’
.51 .1
SNAT 172.16.3.0/24 10.255.0.0/16
.1

10.254.0.0/16
.11
Static NAT Table

Gi0/0
INSIDE OUTSIDE
.10
10.254.0.3 172.16.3.53

.3
iosv-1 .12

38
Data Plane: FLAT Connector Example
VIRL Host
OpenStack Neutron Router
for user ‘Guest’
.51 .1
SNAT 172.16.3.0/24 10.255.0.0/16
.1

.38

Gi0/0
.37

FLAT 172.16.1.0/24
.236
.39

39
‘The Big Connectivity Picture’
• OOB – NATed to SNAT VIRL Host
address space if using OpenStack Neutron Router
for user ‘Guest’
Private [ simulation |
.51 .1
project] networks
SNAT 172.16.3.0/24 10.255.0.0/16 (OOB Management)

40
‘The Big Connectivity Picture’
• OOB – via FLAT has direct VIRL Host
access via FLAT address
space

FLAT 172.16.1.0/24

41
‘The Big Connectivity Picture’
• SNAT connector provides VIRL Host
1:1 static NAT per VM OpenStack Neutron Router
for user ‘Guest’
interface
.51 .1
• FLAT connector has direct SNAT 172.16.3.0/24 10.255.0.0/16 (OOB Management)
access via FLAT address

10.254.0.0/16
space

Data plane
connections

FLAT 172.16.1.0/24 Data plane

connections

42
‘The Big Connectivity Picture’
Private Simulation OOB VIRL Host
Network option (simulations OpenStack Neutron Router
for user ‘Guest’
1,2 & 3) enables users to use
.51 .1
both FLAT and SNAT data
plane access at the same SNAT 172.16.3.0/24 10.255.0.0/16 (OOB Management)

time 2 1

10.254.0.0/16
3
Remember
• OOB network is per-project
-or- per-simulation
4
• SNAT, FLAT and FLAT1
are system-level shared FLAT 172.16.1.0/24
networks

43
VIRL Configuration Bits

44
GitHub 101
When referring to VIRL-Open repo
• Git tool available on the VIRL host
$ git clone …
• direct download as ZIP (no
account needed)
• individual files via cURL or wget
and ‘Raw’ view

get URL download

https://github.com/VIRL-Open/virl-utils to clone archive
https://help.github.com/articles/good-resources-for-learning-git-and-github/ with git
45
VIRL Configuration
User Workspace Manager (UWM): Central Configuration Hub
 pretty much all important settings can be changed here

46
VIRL and DNS
• Working, reachable DNS servers required to avoid name lookup timeouts
• Suggest to use same DNS servers for all configuration entries
• VIRL Server, FLAT, FLAT1 & SNAT networks

47
Dummy Interfaces
• Needed if < 5 NICs on VIRL Host (VM or Bare Metal),
either by design or by necessity
• In /etc/virl.ini set ‘dummy_int: True’
• ‘vinstall salt’ & drive other changes via UWM
• Example

Use dummyX here

48
More on Dummies
• Only FLAT, FLAT1 and SNAT can be changed via
UWM
• ‘Internal Net’ only changeable in /etc/virl.ini
• Entire system can be run ONLY on the management
interface (first / eth0)
• Any other combination possible (2 real / 3 dummy, 3
real / 2 dummy, ...)
• Remember to run ‘vinstall salt’ after any
change in /etc/virl.ini

49
Physical Interface Naming (biosdevname)
• Physical interface names not always eth0, eth1, …
• Driver / Vendor dependent (configurable via udev mappings)
• Use real driver name for mapping in /etc/virl.ini. Example:
• physical interfaces
• p9p1
• P9p2
• p9p3
• p1 & p2 bound into a port channel
• bond0
• split out into VLANs
• bond0.101
• bond0.401

Google(‘ubuntu biosdevname udev’) 50

Note on External Routes
• VIRL Nodes require a route back to VIRL Host
remote networks
• Configuration injection does assign IP
address, but without default route SNAT
• If OOB management interface configured
via DHCP, default route will be set
• Servers usually have a default route

• If working with SNAT or FLAT

connectors, default route must go via
SNAT or FLAT interface, not via OOB User Workstation
management interface
• Otherwise asymmetric routing prevents
communication

51
Secret #1
Trunking

52
What is the problem we’re trying to solve?
• Fan-out simulations to real devices
• Provide separate environments per student / tenant
• Better scale existing FLAT connections
Real VM

Switch ESXi
APIC-EM

?
Student1 NMS NMS

FLAT1
Student2 NMS RADIUS VIRL

FLAT
FLAT
Student3 NMS Workstation

53
 Trunk: Reality Check

100
‘Native’ 200 100 100

200

54
 Trunk: Reality Check

FLAT 100

100
‘Native’ 200 100 100

200
200

55
Use FLAT as a Trunk
• Ultimately, FLAT is a L2 transparent bridge
• FLAT does not care about 802.1q tags
• Nor does it interfere
Benefit: Many networks via
ONE Interface
Trunk
FLAT

Real Virtual
VLAN 200

VLAN 100
56
VIRL Host
Example Real VIRL

• Attach real
User A
devices to real
switch
• Shared VLANs /
networks
User B • Isolate / VRF /
FLAT Route on real
switch
• All on one
User C Interface of VIRL
host
Trunk

57
Wiring
• On Laptops: Use USB Ethernet
Adapters
• Don’t bind any protocol to them
In General, VM settings: Recommend
to disconnect all unused adapters
(FLAT1, SNAT, INT)

58
FLAT – FLAT1 – FLATTER
If more than two (v)NICs / networks are needed:
• Trunking is an alternative, as shown
• Alternatively, create more external networks as
FLAT NICs:
needed 1 2 3 4

• flatter.sh script does that (next slide)

• Requires additional (v)NICs – Measurement cable –

• There is a limit per VM / server, obviously

• We can include this into VIRL if folks do use it DuT
• Let us know!

51
FLAT – FLAT1 – FLATTER
If more than two (v)NICs / networks are needed:
• Trunking is an alternative, as shown
• Alternatively, create more external networks as
FLAT NICs:
needed 1 2 3 4

• flatter.sh script does that (next slide)

• Requires additional (v)NICs – Measurement cable –

• There is a limit per VM / server, obviously

• We can include this into VIRL if folks do use it DuT
• Let us know!

51
More REAL Interfaces Needed?
• Add physical (or virtual) NICs to VIRL host
• Make them available via flatter.sh
script from VIRL-open on GitHub
• Does the heavy lifting for you!
• Use host_network extension to select
network (as with flat1)

61
Demo-Time
• Using the Web Editor
• Separate VLANs from four LXC containers to
IOSv-L2 switch
• Each container is on different VLAN
• Real switch setup to route for VLANs 100-
400
• Trunk from virtual switch to real switch
• Connected to Raspberry Pi (on VLAN 100)
Benefit: Fan-out / multiplex many internal subnets to
external device using a single link / interface
62
Demonstration

63
 Secret #2
OpenVPN without Limits

64
What is the problem we’re trying to solve?
Anyone of the following:
• ESXi VM with only one interface
 don’t run the infra, can’t have arbitrary port groups
• ESXi or bare metal install with limited NICs
• Remote installation of VIRL host, local client talk to VMs on VIRL host
 would need to setup Intranet routing to reach FLAT / FLAT1
• VMs in simulation that need to reach the internet
 package installations on servers
• Security concerns running a VIRL instance
 way too many open ports with no authentication

65
 Assumes
VIRL 1.0
OpenVPN Maximized
Assumption

‘speed limits no longer apply’ road sign

OpenVPN has been setup already (client & server)
Goal
1. Provide complete routing / NAT / PAT
2. Console Access, VM Maestro, IP connectivity,
STD, … all through a single TCP Port
3. Internet Access for nodes (servers, routers, etc.)
4. Secure Server / enable the Firewall
5. Allow 100% use of VIRL via VPN
6. Solution applies globally to the VIRL server

66
Things To Do
1. Make sure DNS settings for FLAT are usable
2. Make sure FLAT gateway points to VIRL host (.254)
3. Have VIRL host do PAT (Masquerade)
4. Enable Firewall (optional)
5. Change STD / Nova serial ports
6. Push additional routes to OpenVPN client
7. Test

67
All-in-One Shortcut 1 2 3 4 5 6

59
All-in-One Shortcut 1 2 3 4 5 6

Will be available as custom Salt state

(included into VIRL)
59
Using UWM 1 2
For FLAT, FLAT1 and SNAT
• Network Address==Gateway
(both .1 or both .254 works)
• Less effort: Change gateway
to .254
• Verify DNS settings
•

• Recommend to reboot host

for good measure

70
Enabling the Firewall on VIRL host 4
• Secure Server, minimize attack surface
• Disable access to unsecured console ports etc.
• Allow only SSH and OpenVPN on the outside
• Might need to open more ports, if needed
• NAT configuration can be integrated

All VIRL services THROUGH VPN

75
The User Friendly Firewall 4
# ufw status
What is it? Status: active

• Default Firewall Frontend on To Action From

-- ------ ----
Ubuntu 22/tcp on eth0 ALLOW Anywhere
443/tcp on eth0 ALLOW Anywhere
• Mostly CLI, system config files Anywhere on eth0 DENY Anywhere (log)
Anywhere ALLOW Anywhere
22/tcp (v6) on eth0 ALLOW Anywhere (v6)
• Not that user friendly, IMO 443/tcp (v6) on eth0 ALLOW Anywhere (v6)
Anywhere (v6) on eth0 DENY Anywhere (v6) (log)
Anywhere (v6) ALLOW Anywhere (v6)
• But has a lot of built-in
intelligence (good default rules)
• Still better than dealing with
iptables manually  Rule Sequence is important!

76
Add Needed Rules 4
Allow SSH
• ufw allow in on eth0 to any port 22 proto tcp Allow
• You might want to move away from 22 to a different, high port applications
(which needs changes in OpenSSH config as well, out-of-scope here) coming in on
outside!
Allow OpenVPN
• ufw allow in on eth0 to any port 443 proto tcp Deny all the
ufw allow in on eth0 to any port 1194 proto udp rest coming in
on outside
• Might want both or only the one actually in use
Allow / Deny everything else Everything
else is
• ufw deny in on eth0 log allowed
ufw allow in from any to any
ufw default allow routed Forwarding

77
Change Nova / STD Configuration 5
• Nova Serial Ports

sudo crudini --set /etc/nova/nova.conf serial_console

proxyclient_address 172.16.1.254
sudo crudini --set /etc/nova/nova.conf DEFAULT
serial_port_proxyclient_address 172.16.1.254
sudo service nova-serialproxy restart
• VIRL STD Address

sudo crudini --set /etc/virl/virl.cfg env virl_local_ip

172.16.1.254
sudo service virl-std restart
sudo service virl-uwm restart crudini = manipulate .ini files
79
Push Additional Routes to Client 6
• Default: Only allow FLAT through tunnel
• Why not route FLAT1 and SNAT (or other networks) in addition?
Note
• Can’t route management IP of VIRL host (loop!)
• For this to work on Windows, OpenVPN client needs to be run as ‘Administrator’
Commands
• echo 'push "route 172.16.0.0 255.255.252.0 172.16.1.254"' |
sudo tee -a /etc/openvpn/server.conf
sudo service openvpn restart

80
Example
• Configure VM Maestro
to use 172.16.1.254
• Check on client that
additional route is
pushed
• Try consoles, UWM

81
 Secret #3
The Combo

82
What is the Problem we’re trying to solve?
• Attach local REAL devices to remote VIRTUAL devices

802.1q capable ESXi VIRL

L2 tunnel

AP PoE Switch
Internet
OpenVPN
Client

Switch optional
(but convenient)

83
The Combo
Goal
• Connect remote physical devices via VPN
using a 802.1q trunk
• Connect a real switch at home remotely to
your VIRL topologies running in your lab!
• Then connect e.g. a sensor, a Windows WAN
laptop, a phone, an Access Point, ANY device
remotely! OpenVPN Client

Here: Connect the local mini-Switch with a

RaspPi to a remote simulation via OpenVPN L2
trunk

84
How do we do this?
• Leverage Bridging Capabilities of OS
• Bridge OpenVPN interface into Ethernet Interface

Real Devices ESXi VIRL

Software
Bridge

85
Create Software Bridge (Windows)
• IP handling / script-ability more
difficult than on *nix
• Therefore needs static IP
• Need to be Administrator

• Select extra Adapter AND

OpenVPN TAP Adapter
• Right Click, select
‘Bridge Connections’

86
Wireshark on the Bridge (Windows)

88
Create Software Bridge (Mac OS X)
Need to bridge VPN interface to REAL interface
• GUI approach won’t show tap interfaces… 
• Create software bridge via CLI
sudo ifconfig bridge99 create
sudo ifconfig bridge99 addm tap0 addm en8
sudo ifconfig bridge99 up
networksetup -setv6off "FLAT USB"
networksetup –setv4off "FLAT USB"
Adapt device name!
• Make sure to use the correct Bridge, Tap and Ethernet device
• Disable IP on tap: ifconfig tap0 0.0.0.0 up

89
Tip: Rename Interfaces
Windows
• Rename in Context menu

Mac OS X
• Here: ‘FLAT USB’
• Figure out BSD device name with

$ networksetup -listnetworkserviceorder

90
Create Software Bridge (Linux)
On the host running the OpenVPN CLIENT
• Need to use brctl utility (Ubuntu package ‘bridge-utils’)
• Alternatively, use ip link
• Make sure no IP addresses are bound to interfaces

# brctl addbr br0 # ip link add br0 type bridge

# brctl addif br0 eth8 # ip link set dev eth8 master br0
# brctl addif br0 tap0 # ip link set dev tap0 master br0
# ifconfig br0 up # ip link set dev br0 up

91
Mac OS X Script ‘openvpn-bridge.sh’
• Automation Script
• ‘setup’: removes addresses from
adapter (only done once)
• ‘create’: after VPN is established
• ‘destroy’: before VPN is
disconnected

https://github.com/VIRL-Open/virl-utils
92
Example: How it behaves
Data Plane
VLAN 100 VLAN 200 VLAN 300
LXC-1

LXC-2
Cat 3560C
10.10.30.0/24
LXC-3

172.16.1.0/24
VIRL

Control Plane

93
 Example: What it actually does!
HERE (Berlin) Internet VIRL
Topo 100
Layer 2 Domain, VLAN 200

100 200
VM 200

Layer 2 Domain, VLAN 100 Remote Data Center / Lab

94
Recommendation
• If you can: Use UDP for the VPN, better performance
• TCP in TCP (in TCP as in my example) is sub-optimal
• Experiment with MTU settings
• USB Ethernet Adapters are really useful
• Most laptops do in fact have two adapters already: Wired and Wireless!

http://serverfault.com/questions/521765/openvpn-to-host-tap-device-having-very-large-mtu

95
Demonstration

96
Conclusion

97
Conclusion
• Network Simulation provides a powerful toolkit
• Tons of APIs at all layers**
• (Almost) nothing is impossible 
• The tools are in your hands now…
• So…
• Play with VIRL
• What can you build?
• Tell others about what you’ve done!
• Post on GitHub!

** Visit DevNet sessions!

98
Links
• Get VIRL
http://virl.cisco.com/ @CiscoVIRL
• Documentation and Video Library
http://virl-dev-innovate.cisco.com/
• User Community
http://community.dev-innovate.com/
cisco.virl
• YouTube Channel
http://www.youtube.com/channel/UC41WuzXlJCGY5qLsuZ8aHkQ
• Utilities, API Sample Code and Sample Topologies
https://github.com/VIRL-Open
Call to Action
• Visit the World of Solutions for
• Cisco Campus
• Walk in Labs
• Technical Solution Clinics

• Meet the Engineer

• Lunch and Learn Topics
• DevNet zone related sessions
Complete Your Online Session Evaluation
• Please complete your online session
evaluations after each session.
Complete 4 session evaluations
& the Overall Conference Evaluation
(available from Thursday)
to receive your Cisco Live T-shirt.

• All surveys can be completed via

the Cisco Live Mobile App or the
Communication Stations
Thank you
 Addendum 1:
VMware Fusion /
Workstation

104
Advanced Network with Fusion and Workstation
• By default, networks are
• Shared with my Mac (NATed)
• Bridged (connected to physical interface)
• Private to my Mac (isolated)

• Custom ‘vmnet’ networks are ‘directly connected’ to host

• But: Usually not routed since host does not forward nor are networks known
outside of host
• NATed networks have a VMware NAT process listening on the x.x.x.2 IP
address / interface
• VMware NAT process can also port-forward from outside to inside (nat.conf)
• Multiple NAT networks can be created

105
Additional vmnet with NAT Fusion Pro
Feature
• Add new ‘Custom’ Network in Fusion
Preferences
• Enable ‘NAT’ for this network
• Connect FLAT to this ‘Custom’
network
• Repeat for FLAT1 and SNAT, if
desired
• vmnet NAT gateway runs on .2, not .1
• Enjoy external connectivity 

106
 Shared Networking on Fusion / Workstation
VMware VIRL Host VM
Workstation / Fusion OpenStack Neutron
Router for user ‘guest’
.1
vmnet4 vNIC 172.16.1.0/24 FLAT
.2
NIC VMware
NAT
Process
.1
vNIC MGMT
VMware
NAT

‘Shared with Process

.2
my Mac’ Host vNIC
.1 172.16.3.0/24 SNAT 10.255.0.0/16
Routing .1
‘Private to Table
my Mac’
107
VMware Workstation / Fusion NAT
• ‘Normal’ interfaces exist on
host.
• Plus NAT processes running
Private to Mac
on .2

Shared with Mac • Packets going to NAT are

sourced from process running
New Network on host
• This is NOT Host IP
forwarding
• Similar MASQUERADING on
Linux
108
DNS and Gateway Adaption
• vmnet-natd process does DHCP, DNS and routing
• Internal networks need to be pointing to it via UWM
• Same way for other subnets (FLAT1, EXT-NET, …)

109
Workstation on Linux and Windows
• Pretty much the same mechanics
• Slightly different places where things are configured (GUI, Paths)
• Linux need promiscuous mode set in a different way[1]
• Make /dev/vmnet* devices r/w accessible for VMware user group
• Assign user to VMware user group
• This permits user to use promiscuous mode

[1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=287

110
 Addendum 2:
Advanced Simulation
Controls

111
Advanced VIRL controls
• Need the ability to set the IP addresses on a VIRL Node rather than letting
DHCP allocate?
• Want the ability to map a certain port for SSH port-forwarding?
• These controls are available but have to be used carefully since IP addresses,
ports etc. are system-level resources

• Let’s see what we can do…

112
VIRL Topology Extensions
• VIRL Topology ‘objects’ can have ‘extensions’ applied via VM Maestro
• Objects can be
• Topology (setting affects the whole topology)
• SNAT/FLAT cloud (connector specific)
• Node (host config or network OS config, if applicable)

• Extensions are Key (or Attribute) Value Pairs

• Some extensions are auto-created by other elements (config extension,
management_network, …)
• Types are ‘String’, ‘Integer’, ‘Boolean’ and ‘Float’
• Extensions define specific object behavior

113
Extension Details
Extension Name Use Example Applies to Notes

host_network Define which host_network=flat1 Topology or FLAT If undefined, ‘flat’ will be used
(string) FLAT network connector
should be used
static_ip Defines a static static_ip=172.16.1.200 FLAT, SNAT objects and Single IP for FLAT networks, IP
(string) IP assignment static_ip=10.254.0.222 nodes for OOB mgmt IP address pair for SNAT mappings
for an object 172.16.3.222 Admin rights required
bound_port References a bound_port=my_static_port FLAT/SNAT connector or Ports must be defined via UWM
(string) pre-configured VM instance
Neutron port to
be used
vlan VLAN number vlan=100 FLAT/SNAT attached to Will insert ‘Float IP’ into interface
(integer) for IP insertion Cisco OS Node Instance that has VLAN 100
subinterface Subinterface subinterface=.100 FLAT/SNAT attached to Will insert ‘Float IP’ into interface
(string) name for IP Cisco OS Node Instance that ends with ‘.100’
insertion

114
Extension Details (cont.)
Extension Name Use Example Applies to Notes

initial config Create file on node initial config script.txt=line1 Cisco IOSv / IOSvL2 node File name is part
(string) disk line2 instance of key (here:
line3 script.txt)
lxc.host.static_ip Define which IP the lxc.host.static_ip=172.16.1.254 If undefined, a
(string) LXC jumphost pool IP will be
should use used
lxc.host.bound_port References a pre- lxc.host.bound_port=lxcport Neutron Port
(string) configured Neutron must be on a flat
Topology set to ‘Use an
port to be used by network
LXC management node’
the LXC jumphost
(management_lxc=true)
lxc.host.tcp_port Defines the TCP lxc.host.tcp_port=12345
(string) port on the VIRL
host the LXC
jumphost is available
on

115
Example: ‘management_network’
• Topology setting ‘Management Network’
sets the extension as a result
• Management network should be ‘flat1’
not ‘flat’?
 Change extension value manually
• management_network can be set to
‘flat’, ‘flat1’, ‘exclusive’ and ‘user’
• ‘flat’ = ‘Shared flat network
‘exclusive’ = ‘Private simulation network’
‘user’ = ‘Private project network’

116
Example: host_network
• Assumption: management_network
set to ‘flat’
• Specific FLAT connector should be
assigned to other network (here: flat1)
• Example shows two FLAT connectors
attached to different networks (flat
and flat1)

117
Admin Rights
• Regular users need ‘admin’ rights if
• static_ip extension is used in topology connected to System-level resource
• System-level resource = FLAT/FLAT1/SNAT outside networks
• User are able to create their own bound ports

• Not needed if admin creates bound ports and regular user just ‘uses’ them
• As the admin user ‘uwmadmin’, add the regular user to admin group in UWM

118
 static_ip addresses
static_ip = 172.16.2.12
static_ip = host_network = flat1
172.16.1.11

static_ip = static_ip =
10.255.0.9 10.255.0.10

static_ip =
10.255.0.11

static_ip = 10.254.0.11 172.16.3.11

119
Add a Bound Port in UWM Bound_port = an IP address
allocated to the project by the
system administrator vs being
requested by the user

120
Example: ‘initial config’ Extension
• Example for File Creation
• Useful to provision a script or other text files into a router instance
• Can be given multiple times

121