Updating JunOS
You can update your version of JunOS from the CLI with the following command:
request system software add [jinstall_package]
Running your router(s)
Now you have a base olive image. Qemu allows you to use this as a base for other images and only writing the changes to your “slave” images saving on disk space! You can also use less memory for each Qemu instance.
Create a new image off of your base image. Repeat for all your routers you want to emulate:
qemu-img create -b olive-base.img -f qcow2 R1.img
Start your router and then telnet to it:
2001 Once logged in, you can type “cli” to launch the JunOS command line interpreter, exit to … exit and halt to shutdown FreeBSD. Remember to kill your qemu instance(s).
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,macaddr=00:aa:00:60:01:01,model=e1000 -net user telnet localhost
Networking your routers
Ok, one router it’s cool but useless alone. It’s time to make your virtual network! There are many ways to network your olive routers.
Olive to Olive using UNIX sockets
UNIX sockets create a TCP stream between two Qemu instances with one a client and the other a server. Apparently this method creates duplicate packets sometimes.
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:01:01,model=e1000 \
-net socket,vlan=1,listen=:6000
qemu R2.img -m 96 -nographic -daemonize -serial telnet::2002,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:01:02,model=e1000 \
-net socket,vlan=1,connect=127.0.0.1:6000
Olive to Olive using UDP tunnels
UDP tunnels are mainly used to connect to Dynamips/GNS3 emulated routers but can also be used as a more reliable way to connect two Qemu olives together but this can result in much lower latency connections as well.
Olive to real world using TAP interface
One way to connect an interface on your Olive with a real Ethernet NIC is to use a bridge and the Qemu tap option.
Linux:
It is required that you have the generic TUN/TAP driver either built-in to your kernel, or available as a module. To check the availability of this module do the following:
ls -la /dev/net/tun
If you get no such file or directory, try doing a modprobe tun. It should then appear in the
lsmod output.
One way to connect an interface on your Olive with a real Ethernet port is to use a bridge and the net -tap option. This requires you to have the generic TUN/TAP driver either built-in to your kernel, or available as a module. To check the availability of this module do the following:
Let’s say you started the emulator with the following:
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
-net tap,vlan=1,script=no
Note the vlan=1 and -net tap options. This basically connects your Olive’s en0 to a virtual tap interface (usually tap0) on your host system. Start up Qemu, and once the emulator is running, proceed to the next step. You’ll need to start up the emulator as root, or change the ownership or permissions on /dev/net/tun.
We’re going to need to now bridge the tap0 interface to another Ethernet interface on the host system. To do this, we’ll utilize the bridge capabilities of Linux. First, get the bridge utilities:
sudo apt-get install bridge-utils
Let’s assume you want to connect en0 on the Olive to eth1 on the host system.
Do the following as root:
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0
This creates a bridge device, br0, and binds the two interfaces to it. Right now everything is still down. Let’s bring it up…
ifconfig eth1 up
ifconfig tap0 up
ifconfig br0 up
Now the bridge and member interfaces should be up. Don’t assign any IP addresses to either of the member interfaces. If you want to, you can assign something to br0 if needed. (br0 is analogous an SVI in the Cisco world) To see the status of the bridge, do the following:
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000cf19ce06c no eth1
tap0
Now, assign an IP address to the em0 interface on your Olive, and it should be online. You are also free to tcpdump on the bridge or member interfaces, for debugging. All of this can probably be put into a Qemu interface script, so you can remove the script=no option, and make it a little more automatic.
Your kernel might have ethernet filtering (ebtables, bridge-nf, arptables) enabled, and traffic gets filtered except ARP and STP. The easiest way to disable this is to go to /proc/sys/net/bridge. Check if the bridge-nf-* entries in there are set to 1; in that case, set them to zero and try again. More information on bridges available here.
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done
Windows:
Using OpenVPN you can create several tap interfaces with “Add a new TAP-Win32 virtual Ethernet adapter” and rename them with something like ‘Tap1′, ‘Tap2′ and so on Let’s say we have created 1 Tap interface and renamed it as Tap1. Right click this Tap1 interface on Windows Control Panel – Network Connections and give IP address for example 10.1.1.1/8.
Now you can start Qemu with the -net tap option and ping the interface from your Olive:
qemu -L . -m 96 -hda R1.img -localtime \
-net nic,vlan=1,macaddr=00:aa:00:60:01:01,model=e1000 \
-net tap,vlan=1,ifname=tap0
Mac OS X
On Mac OS X, download and install the TunTap package.
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
-net tap,vlan=1,ifname=tap0,script=no
We need to give this inter face an ip address:
sudo ifconfig tap0 198.18.0.250/24 up
Olive to real world using PCAP/LACPIn the patch provided in this howto, there is an option to use PCAP or LCAP libraries to bridge directly to a physical interface. You will probable need to run Qemu under Administrator privileges. Please also note that it will stop any other traffic on your interface.
For PCAP:
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,macaddr=00:aa:00:60:01:01,model=e1000 \
-net pcap,ifname=eth0
For LCAP:
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,macaddr=00:aa:00:60:01:01,model=e1000 \
-net lcap,ifname=eth0
Please note that you have to configure an IP address your physical interface before being able to communication between your routers. Also I didn’t test PCAP/LCAP on Windows.
Olive to Dynamips or Pemu
The lastest patch also added a udp option to allow networking to a Dynamips or pemu.
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
-net udp,vlan=1,sport=10000,dport=10001,daddr=127.0.0.1
Then in your dynagen .net file
[[router Cisco1]]
fa0/0=NIO_udp:10001:127.0.0.1:10000
Olive to GNS3
Under GNS3, you can create a “Cloud” and configure a NIO UDP (you can add as many NIO UDP as you want). The “Cloud” will be your interface between Olive and GNS3, you can link a firewall or a router per NIO UDP.
Of course, you can do the same with other NIOs like NIO TAP to connect to yourolive using a TAP interface.
Testing
To check if everything work, let’s configure 2 Olives:
root@%cli
root>edit
[edit]
root#
[edit]
root#set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
root#set interfaces em0 unit 0 family inet address 10.0.0.1/8
[edit]
root#commit
commit complete
Configure the other device using the same commands but with another IP address (e.g. 10.0.0.2/8) and ping.
root#exit
Exiting configuration mode
root> ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=9.771 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.614 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.693 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.630 ms
Additionally, configure OSPF (or any other multicast based protocol) to test if your routers can talk to each other using multicast packets. Again, type those commands on both routers:
root# set protocols ospf area 0 interface em0
[edit]
root# commit
commit complete
[edit]
root# exitExiting configuration mode
Then monitor the traffic from one of the router, you should see some multicast traffic (from/to 224.0.0.5):
root> monitor traffic interface em0
02:30:30.973748 Out IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 48
02:30:31.007675 In IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 48
Is everything working? yes? then you are successfully running JunOS! Happy networking
What is working
Here is a list of what has been tested and works. You can extend this list by posting comments on what is working or not for you and I’ll update the list:
OSPF (fxp0) OK
OSPF (em0) OK
A few words about the patch By default using JunOS with a non-patched Qemu, multicast based protocols didn’t worked. As I have very little driver coding experience (and time to learn), I patched Qemu to allow multicast frames to be received by JunOS, instead of being filtered at the driver level multicast frames are filtered by JunOS. The only problem I see could be on the performance side, as JunOS receives every multicast frames, even those not destined to it. However, I think this is not an issue for a simulated lab environments and it worked just fine so far.
If you feel you can do something cleaner, please don’t hesitate, you can still read one of the Intel manuals concerning the e1000 to have an overview of how complicated driver programming can be.
Conclusion
If you are IT guy (hope you are if you want to play with JunOS), you should be able to run JunOS on your PC without too many issues. I wrote this howto to be as complete as possible, showing how to compile and patch Qemu on 3 different operating systems, installing FreeBSD and JunOS. I encourage everyone to contribute to it by providing fixes, comments or any other help.
You can update your version of JunOS from the CLI with the following command:
request system software add [jinstall_package]
Running your router(s)
Now you have a base olive image. Qemu allows you to use this as a base for other images and only writing the changes to your “slave” images saving on disk space! You can also use less memory for each Qemu instance.
Create a new image off of your base image. Repeat for all your routers you want to emulate:
qemu-img create -b olive-base.img -f qcow2 R1.img
Start your router and then telnet to it:
2001 Once logged in, you can type “cli” to launch the JunOS command line interpreter, exit to … exit and halt to shutdown FreeBSD. Remember to kill your qemu instance(s).
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,macaddr=00:aa:00:60:01:01,model=e1000 -net user telnet localhost
Networking your routers
Ok, one router it’s cool but useless alone. It’s time to make your virtual network! There are many ways to network your olive routers.
Olive to Olive using UNIX sockets
UNIX sockets create a TCP stream between two Qemu instances with one a client and the other a server. Apparently this method creates duplicate packets sometimes.
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:01:01,model=e1000 \
-net socket,vlan=1,listen=:6000
qemu R2.img -m 96 -nographic -daemonize -serial telnet::2002,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:01:02,model=e1000 \
-net socket,vlan=1,connect=127.0.0.1:6000
Olive to Olive using UDP tunnels
UDP tunnels are mainly used to connect to Dynamips/GNS3 emulated routers but can also be used as a more reliable way to connect two Qemu olives together but this can result in much lower latency connections as well.
Olive to real world using TAP interface
One way to connect an interface on your Olive with a real Ethernet NIC is to use a bridge and the Qemu tap option.
Linux:
It is required that you have the generic TUN/TAP driver either built-in to your kernel, or available as a module. To check the availability of this module do the following:
ls -la /dev/net/tun
If you get no such file or directory, try doing a modprobe tun. It should then appear in the
lsmod output.
One way to connect an interface on your Olive with a real Ethernet port is to use a bridge and the net -tap option. This requires you to have the generic TUN/TAP driver either built-in to your kernel, or available as a module. To check the availability of this module do the following:
Let’s say you started the emulator with the following:
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
-net tap,vlan=1,script=no
Note the vlan=1 and -net tap options. This basically connects your Olive’s en0 to a virtual tap interface (usually tap0) on your host system. Start up Qemu, and once the emulator is running, proceed to the next step. You’ll need to start up the emulator as root, or change the ownership or permissions on /dev/net/tun.
We’re going to need to now bridge the tap0 interface to another Ethernet interface on the host system. To do this, we’ll utilize the bridge capabilities of Linux. First, get the bridge utilities:
sudo apt-get install bridge-utils
Let’s assume you want to connect en0 on the Olive to eth1 on the host system.
Do the following as root:
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0
This creates a bridge device, br0, and binds the two interfaces to it. Right now everything is still down. Let’s bring it up…
ifconfig eth1 up
ifconfig tap0 up
ifconfig br0 up
Now the bridge and member interfaces should be up. Don’t assign any IP addresses to either of the member interfaces. If you want to, you can assign something to br0 if needed. (br0 is analogous an SVI in the Cisco world) To see the status of the bridge, do the following:
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000cf19ce06c no eth1
tap0
Now, assign an IP address to the em0 interface on your Olive, and it should be online. You are also free to tcpdump on the bridge or member interfaces, for debugging. All of this can probably be put into a Qemu interface script, so you can remove the script=no option, and make it a little more automatic.
Your kernel might have ethernet filtering (ebtables, bridge-nf, arptables) enabled, and traffic gets filtered except ARP and STP. The easiest way to disable this is to go to /proc/sys/net/bridge. Check if the bridge-nf-* entries in there are set to 1; in that case, set them to zero and try again. More information on bridges available here.
# cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done
Windows:
Using OpenVPN you can create several tap interfaces with “Add a new TAP-Win32 virtual Ethernet adapter” and rename them with something like ‘Tap1′, ‘Tap2′ and so on Let’s say we have created 1 Tap interface and renamed it as Tap1. Right click this Tap1 interface on Windows Control Panel – Network Connections and give IP address for example 10.1.1.1/8.
Now you can start Qemu with the -net tap option and ping the interface from your Olive:
qemu -L . -m 96 -hda R1.img -localtime \
-net nic,vlan=1,macaddr=00:aa:00:60:01:01,model=e1000 \
-net tap,vlan=1,ifname=tap0
Mac OS X
On Mac OS X, download and install the TunTap package.
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
-net tap,vlan=1,ifname=tap0,script=no
We need to give this inter face an ip address:
sudo ifconfig tap0 198.18.0.250/24 up
Olive to real world using PCAP/LACPIn the patch provided in this howto, there is an option to use PCAP or LCAP libraries to bridge directly to a physical interface. You will probable need to run Qemu under Administrator privileges. Please also note that it will stop any other traffic on your interface.
For PCAP:
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,macaddr=00:aa:00:60:01:01,model=e1000 \
-net pcap,ifname=eth0
For LCAP:
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,macaddr=00:aa:00:60:01:01,model=e1000 \
-net lcap,ifname=eth0
Please note that you have to configure an IP address your physical interface before being able to communication between your routers. Also I didn’t test PCAP/LCAP on Windows.
Olive to Dynamips or Pemu
The lastest patch also added a udp option to allow networking to a Dynamips or pemu.
qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait \
-localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 \
-net udp,vlan=1,sport=10000,dport=10001,daddr=127.0.0.1
Then in your dynagen .net file
[[router Cisco1]]
fa0/0=NIO_udp:10001:127.0.0.1:10000
Olive to GNS3
Under GNS3, you can create a “Cloud” and configure a NIO UDP (you can add as many NIO UDP as you want). The “Cloud” will be your interface between Olive and GNS3, you can link a firewall or a router per NIO UDP.
Testing
To check if everything work, let’s configure 2 Olives:
root@%cli
root>edit
[edit]
root#
[edit]
root#set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
root#set interfaces em0 unit 0 family inet address 10.0.0.1/8
[edit]
root#commit
commit complete
Configure the other device using the same commands but with another IP address (e.g. 10.0.0.2/8) and ping.
root#exit
Exiting configuration mode
root> ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=9.771 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.614 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.693 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.630 ms
Additionally, configure OSPF (or any other multicast based protocol) to test if your routers can talk to each other using multicast packets. Again, type those commands on both routers:
root# set protocols ospf area 0 interface em0
[edit]
root# commit
commit complete
[edit]
root# exitExiting configuration mode
Then monitor the traffic from one of the router, you should see some multicast traffic (from/to 224.0.0.5):
root> monitor traffic interface em0
02:30:30.973748 Out IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length 48
02:30:31.007675 In IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 48
Is everything working? yes? then you are successfully running JunOS! Happy networking
What is working
Here is a list of what has been tested and works. You can extend this list by posting comments on what is working or not for you and I’ll update the list:
OSPF (fxp0) OK
OSPF (em0) OK
A few words about the patch By default using JunOS with a non-patched Qemu, multicast based protocols didn’t worked. As I have very little driver coding experience (and time to learn), I patched Qemu to allow multicast frames to be received by JunOS, instead of being filtered at the driver level multicast frames are filtered by JunOS. The only problem I see could be on the performance side, as JunOS receives every multicast frames, even those not destined to it. However, I think this is not an issue for a simulated lab environments and it worked just fine so far.
If you feel you can do something cleaner, please don’t hesitate, you can still read one of the Intel manuals concerning the e1000 to have an overview of how complicated driver programming can be.
Conclusion
If you are IT guy (hope you are if you want to play with JunOS), you should be able to run JunOS on your PC without too many issues. I wrote this howto to be as complete as possible, showing how to compile and patch Qemu on 3 different operating systems, installing FreeBSD and JunOS. I encourage everyone to contribute to it by providing fixes, comments or any other help.
No comments:
Post a Comment