DHCPD and the mysterious “host unknown”

Posted on Leave a commentPosted in CentOS 7, DHCP, DNS, Fedora, Linux, RHEL 7

For those of you following my “back to basics” series, in my last post setting up a dhcp server, I finished up with an error that flummoxed me initially.

Feb 22 22:13:36 rhc-server dhcpd[2682]: ns.lab.tobyheywood.com: host unknown.<br />
Feb 22 22:13:36 rhc-server dhcpd[2682]: rtr.lab.tobyheywood.com: host unknown.

I had tried;

  • pinging the supposedly unknown hosts
    • both locally on the server which has the named daemon on it
    • remotely from the client that had just been assigned an IP address from my newly installed dhcp server
  • used tools such as dig to confirm the zone looked fine
  • double checked the dhcpd.conf file
  • nothing stood out as being odd
  • So, as it was late, I went to bed with the determination that I would research and fix the issue before me!

So I started reading through the dhcpd.conf man page (an online version though no guarantee it’s the latest version, can be found here http://linux.die.net/man/5/dhcpd.conf).

After scanning through the first few sections, I began reading about the steps required to setup Dynamic DNS Updates (ddns) and spied the recommendations regarding securing the dynamic DNS configuration. And something suddenly occurred to me… I hadn’t created a reverse lookup zone!!!

To the bat cave!

Now before I begin, there are two things I should mention;

  1. It’s good to reboot
  2. After rebooting my virtual machines it fixed my issue, but I suspect something had not refreshed as both the DNS and DHCP servers were created in the same evening.  I had also made modifications to my NIC setup to reflect the fact that I now had a local DNS server.
  3. Bonus material, I shall continue with the reverse zone creation steps.

Just to double check that I am setting up my reverse zone, I also consulted the current documentation for Red Hat Enterprise Linux 7 (essential CentOS 7) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html#sec-bind-zone.  I guess now is a good time to mention the fact that Red Hat does have some awesome documentation and you really should take the time to read all of it (which I have), as quite often not only do you find out the bits of information you were looking for but also you will find some interesting shortcuts and new ways of doing things.

Anyway…

Creating a reverse zone

So my reverse zone file looks like this

[root@rhc-server data]# cat lab.tobyheywood.com.rr.zone<br />
$ORIGIN 20.168.192.in-addr.arpa.<br />
$TTL 1d<br />
@    IN    SOA    ns.lab.tobyheywood.com.    hostmaster.lab.tobyheywood.com. (<br />
2016022400    ; Serial<br />
6h        ; Refresh<br />
1h        ; Retry<br />
2d        ; Expire<br />
1d )        ; Minimum TTL<br />
;<br />
@    IN    NS    ns.lab.tobyheywood.com.<br />
;<br />
1    IN    PTR    rhc-server.lab.tobyheywood.com.<br />

Annoyingly the formatting seems to ignore tabs and multiple spacing where I put the code snippets on my website but I can assure you it is all neatly indented to ensure easy reading.

And I also added the following into the /etc/named.conf file;

[root@rhc-server data]# cat /etc/named.conf<br />
options {<br />
listen-on port 53 { 192.168.20.1; };<br />
//listen-on-v6 port 53 { ::1; };<br />
directory     &quot;/var/named&quot;;<br />
dump-file     &quot;/var/named/data/cache_dump.db&quot;;<br />
statistics-file &quot;/var/named/data/named_stats.txt&quot;;<br />
memstatistics-file &quot;/var/named/data/named_mem_stats.txt&quot;;<br />
allow-query     { any; };</p>
<p>dnssec-enable yes;<br />
dnssec-validation yes;<br />
dnssec-lookaside auto;</p>
<p>/* Path to ISC DLV key */<br />
bindkeys-file &quot;/etc/named.iscdlv.key&quot;;</p>
<p>managed-keys-directory &quot;/var/named/dynamic&quot;;</p>
<p>pid-file &quot;/run/named/named.pid&quot;;<br />
session-keyfile &quot;/run/named/session.key&quot;;<br />
};</p>
<p>logging {<br />
channel default_debug {<br />
file &quot;data/named.run&quot;;<br />
severity dynamic;<br />
};<br />
};</p>
<p>zone &quot;.&quot; IN {<br />
type hint;<br />
file &quot;named.ca&quot;;<br />
};</p>
<p>zone &quot;lab.tobyheywood.com&quot; IN {<br />
type master;<br />
file &quot;data/lab.tobyheywood.com&quot;;<br />
allow-update { none; };<br />
};</p>
<p>zone &quot;20.168.192.in-addr.arpa&quot; IN {<br />
type master;<br />
file &quot;data/lab.tobyheywood.com.rr.zone&quot;;<br />
allow-update { none; };<br />
};</p>
<p>include &quot;/etc/named.rfc1912.zones&quot;;<br />
include &quot;/etc/named.root.key&quot;;<br />

Now I spotted that “recursion yes” had not be commented whilst I was adding the new zone “20.168.192.in-addr.arpa”.  This is unwanted as I do not want the server to be a caching DNS server, I’m only interested at this time in it providing my internal host details and nothing more.

[root@rhc-server data]# dig -x 192.168.20.1</p>
<p>; &lt;&lt;&gt;&gt; DiG 9.9.4-RedHat-9.9.4-14.el7 &lt;&lt;&gt;&gt; -x 192.168.20.1<br />
;; global options: +cmd<br />
;; Got answer:<br />
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 45831<br />
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2</p>
<p>;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
;; QUESTION SECTION:<br />
;1.20.168.192.in-addr.arpa.    IN    PTR</p>
<p>;; ANSWER SECTION:<br />
1.20.168.192.in-addr.arpa. 86400 IN    PTR    rhc-server.lab.tobyheywood.com.</p>
<p>;; AUTHORITY SECTION:<br />
20.168.192.in-addr.arpa. 86400    IN    NS    ns.lab.tobyheywood.com.</p>
<p>;; ADDITIONAL SECTION:<br />
ns.lab.tobyheywood.com.    86400    IN    A    192.168.20.1</p>
<p>;; Query time: 0 msec<br />
;; SERVER: 192.168.20.1#53(192.168.20.1)<br />
;; WHEN: Wed Feb 24 23:20:47 GMT 2016<br />
;; MSG SIZE  rcvd: 131<br />

And there we have it, a reverse DNS zone has been born!  Yay!

Network bonding vs teaming in Linux

Posted on Leave a commentPosted in Fedora, Linux, RHEL 7

The terms bonding and teaming are quite often used interchangeably, especially when wearing both Linux and Microsoft hats.  And that term is further confused once you start wearing your network admin hat as well.

However, in the world of Linux (in my case Fedora/CentOS/RHEL) there are distinct differences between the terms.  One is the future of network interface collaboration, whilst the other is still very much capable, it lacks some of the features people may find useful going forward.

And to quote the Red Hat Enterprise Linux 7 Networking Guide;

“The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as channel bonding, Ethernet bonding, port trunking, channel teaming, NIC teaming, link aggregation, and so on. This concept as originally implemented in the Linux kernel is widely referred to as bonding. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in Red Hat Enterprise Linux 7. “

So why should you consider adopting teaming rather than the bonding method?

If you are looking for a complete comparison from the horses mouth, then may I suggest the; Red Hat Enterprise Linux Networking Guide: Comparison of Network Teaming to Bonding.

The key reasons why you might want to use teaming rather than bonding are;

  • Teaming has a small kernel module which implements fast handling of packets flowing through your teamed interfaces
  • support for IPv6 (NS/NA) link monitoring
  • Capable of working with D-Bus and Unix Domain Sockets (the default)
  • It provides an extensible and scale-able solution for your teaming requirements
  • load balancing for LACP support
  • It makes use of NetworkManager and its associates tools (the modern way) to manage your network connections

For me, I see teamd as ultimately the replacement for bonding in the coming years.  Especially given that you can make use of tools such as nmcli which means that automation and repeatable configuration becomes much simper as the cli tools remove a lot of the checking and verification steps you would ultimately want when developing your own scripts to do the same job in a more manual fashion.

Obviously, NetworkManager has been around for a while so standard configurations could be applied using the likes of nmcli, but for anything more involved (see above reasons why you might consider teamd) then it becomes a no-brainer!

Anyway, I would highly recommend reading the Red Hat Enterprise Linux 7 documentation, there are some amazing nuggets of information in there.

Enabling GNS3 to talk to it’s host and beyond

Posted on Leave a commentPosted in Fedora, GNS3, Linux, Networking, Networks, RHEL 7, System Administration

I’m currently working my way through a CCNA text book and reached a point where I need to be able perform some tasks which rely on connecting the virtual network environment inside of GNS3 to the host machine, for the purpose of connecting to a tftp service (just in case you were curious).

After a little googling it became apparent that this is indeed possible, though most of the guides focused on using GNS3 on a Windows machine. Where as I, am very much a Linux guy.

So as a reminder to myself but also as a helpful reference for others here is what I had to do on my Fedora 22 machine

The first way was using standard tools in Linux, the second I made sure I was able to create the same setup using Network Manager (again to make sure that I am utilising the latest tools for the job).

Standard method (from the command line)

$ sudo dnf install tunctl<br />
$ tunctl -t tap0 -u toby<br />
$ ifconfig tap0 10.0.1.10 netmask 255.255.255.0 up<br />
$ firewall-cmd --zone=FedoraWorkstation --add-interface=tap0 --permanent

 

Using Network Manager (from the command line)

$ sudo ip tuntap add dev tap1 mode tap user toby<br />
$ sudo ip addr add 10.0.0.10/255.255.255.0 dev tap1<br />
$ sudo ip link set tap1 up<br />
$ sudo firewall-cmd --zone=FedoraWorkstation --add-interface=tap1<br />
$ sudo ip addr show tap1<br />
11: tap1: &lt;broadcast,multicast,up,lower_up&gt; mtu 1500 qdisc fq_codel state UP group default qlen 500<br />
link/ether 26:2b:e4:a0:54:ba brd ff:ff:ff:ff:ff:ff<br />
inet 10.0.0.10/24 scope global tap1<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::242b:e4ff:fea0:54ba/64 scope link<br />
valid_lft forever preferred_lft forever<br />

Configuring the interface on the Cisco router inside of GNS3

router1#conf t<br />
Enter configuration commands, one per line.  End with CNTL/Z.<br />
router1(config)#int f0/0<br />
router1(config-if)#ip address 10.0.0.1 255.255.255.0<br />
router1(config-if)#no shut<br />
router1(config)<br />
router1&gt;write mem<br />

The bit of config inside GNS3

I nearly forgot to write this section.  Doh!  Anyway, it’s lucky for everyone that I remember, so without any further padding… seriously, no more padding… the config in GNS3…

GNS3_Side_Panel
Select Cloud from the side panel in GNS3.

Next we need to configure the cloud… (hint.  right click the cloud and select configure).

GNS3_tap1_configuration_screen
Select TAP and then type in the name of the tap device created, in my case tap1.

The final step is to draw the virtual connection between the cloud and the router (making sure to map it to the correct interface).

At this point we should be in a happy place.

Proof that it works

# ping -c 5 10.0.0.10<br />
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.<br />
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=0.103 ms<br />
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=0.096 ms<br />
64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=0.050 ms<br />
64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=0.058 ms<br />
64 bytes from 10.0.0.10: icmp_seq=5 ttl=64 time=0.103 ms</p>
<p>--- 10.0.0.10 ping statistics ---<br />
5 packets transmitted, 5 received, 0% packet loss, time 3999ms<br />
rtt min/avg/max/mdev = 0.050/0.082/0.103/0.023 ms<br />
# ping -c 5 10.0.0.1<br />
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.<br />
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=9.16 ms<br />
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=5.64 ms<br />
64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=11.2 ms<br />
64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=7.29 ms<br />
64 bytes from 10.0.0.1: icmp_seq=5 ttl=255 time=2.98 ms</p>
<p>--- 10.0.0.1 ping statistics ---<br />
5 packets transmitted, 5 received, 0% packet loss, time 4005ms<br />
rtt min/avg/max/mdev = 2.980/7.266/11.253/2.847 ms</p>
<p>router1#ping 10.0.0.10</p>
<p>Type escape sequence to abort.<br />
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:<br />
.!!!!<br />
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/9/12 ms<br />

I do believe that about covers.

GNS3 – Problems Compiling IOUYAP

Posted on Leave a commentPosted in C++, Fedora, Linux, Networks

Following the series of posts over recent months relating to the installation of GNS3; 1) Installing GNS3 on Fedora, CentOS and RHEL and 2) GNS3 Installation on Fedora 22 I have decided to put together a complete guide from start to finish chronicling my every step to ensure my GNS3 installation is correct and fully working.

It is at this point that I feel that I should not just share the normal story of “everything went fine… what problems?? I didn’t have a single issue installing the software!!!”  Well, for the most part I could have got away with a statement like that.  Unfortunately though when I reached the point of installing iouyap, things didn’t go quite as smoothly as one would hope.

As per my previous guides and the instructions that ship with iouyap (version 0.95) I ran the following;

$ bison --yacc -dv netmap_parse.y<br />
$ flex netmap_scan.l<br />
$ gcc -Wall -g *.c -o iouyap -liniparser -lpthread

I was the confronted with a wall of potential errors, and not knowing exactly what they meant, I thought it best to investigate…  The output from the last command line above was;

[toby@thebay iouyap-0.95]$ sudo gcc -Wall -g *.c -o iouyap -liniparser -lpthread<br />
In file included from iouyap.c:49:0:<br />
iouyap.c: In function ‘foreign_listener’:<br />
iouyap.c:420:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]<br />
debug_log_fmt (&quot;received %d bytes (sfd=%d)\n&quot;,<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
iouyap.h:128:5: note: in expansion of macro ‘STMT’<br />
STMT( log_prefix(); fprintf(stderr, fmt, ## __VA_ARGS__); )<br />
^<br />
iouyap.h:138:26: note: in expansion of macro ‘log_fmt’<br />
STMT( if (DEBUG_LOG) log_fmt(fmt, ## __VA_ARGS__); )<br />
^<br />
iouyap.c:420:9: note: in expansion of macro ‘debug_log_fmt’<br />
debug_log_fmt (&quot;received %d bytes (sfd=%d)\n&quot;,<br />
^<br />
iouyap.c:458:28: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]<br />
log_fmt (&quot;sendto() only sent %d of %d bytes!&quot;<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
iouyap.c:458:19: note: in expansion of macro ‘log_fmt’<br />
log_fmt (&quot;sendto() only sent %d of %d bytes!&quot;<br />
^<br />
iouyap.c:458:28: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘ssize_t {aka long int}’ [-Wformat=]<br />
log_fmt (&quot;sendto() only sent %d of %d bytes!&quot;<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
iouyap.c:458:19: note: in expansion of macro ‘log_fmt’<br />
log_fmt (&quot;sendto() only sent %d of %d bytes!&quot;<br />
^<br />
iouyap.c: In function ‘iou_listener’:<br />
iouyap.c:536:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]<br />
debug_log_fmt (&quot;received %d bytes for port %d (sfd=%d)\n&quot;,<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
iouyap.h:128:5: note: in expansion of macro ‘STMT’<br />
STMT( log_prefix(); fprintf(stderr, fmt, ## __VA_ARGS__); )<br />
^<br />
iouyap.h:138:26: note: in expansion of macro ‘log_fmt’<br />
STMT( if (DEBUG_LOG) log_fmt(fmt, ## __VA_ARGS__); )<br />
^<br />
iouyap.c:536:9: note: in expansion of macro ‘debug_log_fmt’<br />
debug_log_fmt (&quot;received %d bytes for port %d (sfd=%d)\n&quot;,<br />
^<br />
iouyap.c:563:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ssize_t {aka long int}’ [-Wformat=]<br />
log_fmt (&quot;write() only sent %d of %d bytes! (sfd=%d)\n&quot;,<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
iouyap.c:563:15: note: in expansion of macro ‘log_fmt’<br />
log_fmt (&quot;write() only sent %d of %d bytes! (sfd=%d)\n&quot;,<br />
^<br />
iouyap.c:563:24: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘ssize_t {aka long int}’ [-Wformat=]<br />
log_fmt (&quot;write() only sent %d of %d bytes! (sfd=%d)\n&quot;,<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
iouyap.c:563:15: note: in expansion of macro ‘log_fmt’<br />
log_fmt (&quot;write() only sent %d of %d bytes! (sfd=%d)\n&quot;,<br />
^<br />
In file included from netmap.c:34:0:<br />
netmap.c: In function ‘dump_port_table’:<br />
netmap.c:372:16: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘size_t {aka long unsigned int}’ [-Wformat=]<br />
log_fmt (&quot;%d:%d/%d talks to %d other node(s):\n&quot;, yap_appl_id,<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
netmap.c:372:7: note: in expansion of macro ‘log_fmt’<br />
log_fmt (&quot;%d:%d/%d talks to %d other node(s):\n&quot;, yap_appl_id,<br />
^

After some monkeying about, I reduced these errors to;

In file included from netmap.c:34:0:<br />
netmap.c: In function ‘dump_port_table’:<br />
netmap.c:372:16: warning: format ‘%d’ expects argument of type ‘int’, but argument 6 has type ‘size_t {aka long unsigned int}’ [-Wformat=]<br />
log_fmt (&quot;%d:%d/%d talks to %d other node(s):\n&quot;, yap_appl_id,<br />
^<br />
iouyap.h:103:28: note: in definition of macro ‘STMT’<br />
#define STMT( code )  do { code } while (0)<br />
^<br />
netmap.c:372:7: note: in expansion of macro ‘log_fmt’<br />
log_fmt (&quot;%d:%d/%d talks to %d other node(s):\n&quot;, yap_appl_id,<br />
^<br />

the diff output is as follows;

diff iouyap.c ../../iouyap-0.95_original/iouyap-0.95/iouyap.c
383,384c383
<   /* ssize_t bytes_received, bytes_sent; */
<   int bytes_received, bytes_sent; --- >   ssize_t bytes_received, bytes_sent;
503,504c502
<   /* ssize_t bytes_received, bytes_sent; */
<   int bytes_received, bytes_sent; --- >   ssize_t bytes_received, bytes_sent;

Now I’m no C++ developer, not even close, and the last thing to resolve in netmap.c just didn’t make sense. So I paid the gns3 website a visit, and magically less than 24 hours after I had downloaded the 1.3.8 version there was a new release… 1.3.9.

Sadly the IOUYAP package there also contained the issue, in the end I resorted to good old fashioned tactics… I got hold of the source code from github and the issues I was facing were fixed in the version I checked out.  You can see the results below;

[toby@thebay GNS3-1.3.9]$ git clone https://github.com/GNS3/iouyap.git<br />
Cloning into 'iouyap'...<br />
remote: Counting objects: 78, done.<br />
remote: Total 78 (delta 0), reused 0 (delta 0), pack-reused 78<br />
Unpacking objects: 100% (78/78), done.<br />
Checking connectivity... done.<br />
[toby@thebay GNS3-1.3.9]$ ls<br />
dynamips-0.2.14      gns3-gui-1.3.9      gns3-server-1.3.9      iouyap       iouyap-0.95.zip  ubridge-0.9.0.zip  vpcs-0.6.1.zip<br />
dynamips-0.2.14.zip  gns3-gui-1.3.9.zip  gns3-server-1.3.9.zip  iouyap-0.95  ubridge-0.9.0    vpcs-0.6.1<br />
[toby@thebay GNS3-1.3.9]$ cd iouyap<br />
[toby@thebay iouyap]$ ls<br />
config.c  dictionary.h  iouyap.c  iouyap.ini  Makefile  netmap.c  netmap_parse.y  README.rst<br />
config.h  iniparser.h   iouyap.h  LICENSE     NETMAP    netmap.h  netmap_scan.l<br />
[toby@thebay iouyap]$ make<br />
gcc  -g -DDEBUG -Wall   -c -o iouyap.o iouyap.c<br />
bison -y -d netmap_parse.y<br />
mv -f y.tab.c netmap_parse.c<br />
gcc  -g -DDEBUG -Wall   -c -o netmap_parse.o netmap_parse.c<br />
flex  -t netmap_scan.l &gt; netmap_scan.c<br />
gcc  -g -DDEBUG -Wall   -c -o netmap_scan.o netmap_scan.c<br />
gcc  -g -DDEBUG -Wall   -c -o netmap.o netmap.c<br />
gcc  -g -DDEBUG -Wall   -c -o config.o config.c<br />
gcc    iouyap.o netmap_parse.o netmap_scan.o netmap.o config.o  -liniparser -lpthread -o iouyap<br />
rm netmap_scan.c netmap_parse.c<br />
[toby@thebay iouyap]$ sudo make install<br />
[sudo] password for toby:<br />
chmod +x iouyap<br />
sudo cp iouyap /usr/local/bin<br />
sudo setcap cap_net_admin,cap_net_raw=ep iouyap<br />

Taa Daa!

GNS3 Installation on Fedora 22

Posted on Leave a commentPosted in Fedora, Linux, Networking, Networks

Following on from one of my earlier posts installing GNS3 on Fedora, CentOS and RHEL, it would appear that things have changed a little once you are on Fedora 22.

The following details the steps requred to get up and running with GNS3 on Fedora 22.

When I tried to install the pre-requisites based on my original post, I got the following error;

Error: Transaction check error:<br />
file /usr/bin/pylupdate4 conflicts between attempted installs of python3-PyQt4-devel-4.11.3-5.fc22.i686 and python3-PyQt4-devel-4.11.3-5.fc22.x86_64<br />
file /usr/bin/pyrcc4 conflicts between attempted installs of python3-PyQt4-devel-4.11.3-5.fc22.i686 and python3-PyQt4-devel-4.11.3-5.fc22.x86_64<br />

Obtaining the files

If you download the latest GNS3 zip file it will contain pretty much everything you need (apart from the require packages to build the different applications, see below).

https://community.gns3.com/community/software/download/

Note.  You will need to register.

Pre-reqs – GNS3 Generic

sudo dnf install python3-setuptools python3-devel python3-sip.i686 python3-sip.x86_64 python3-PyQt4.i686 python3-PyQt4.x86_64 python3-PyQt4-devel.i686 python3-net*

Note.  Fedora 22 now uses dnf for package management and yum is depreciated.  If you do run yum it will redirect your request to dnf.

Installation of dynamiqs

You will need to make sure you have the required pre-req packages as detailed below.

$ sudo dnf gcc gcc-c++ elfutils-libelf-devel libuuid-devel libuuid-devel cmake

And then the process to build remains the same;

&lt;/pre&gt;</p>
<p>$ cd /path/to/gns3_source/dynamips_extracted_folder<br />
$ mkdir build<br />
$ cd build<br />
$ cmake ..<br />
$ sudo make install<br />

Installation of GNS3-GUI

&lt;code class=&quot;bash plain&quot;&gt;&lt;/code&gt;&lt;code class=&quot;bash functions&quot;&gt;&lt;/code&gt;&lt;code class=&quot;bash plain&quot;&gt;&lt;/code&gt;&lt;code class=&quot;bash functions&quot;&gt;&lt;/code&gt;$ cd /path/to/gns3_source/gns3-gui<br />
$ sudo python3 setup.py install

Installation of GNS3-Server

$ cd ../gns3-server-1.3.7/<br />
$ sudo python3 setup.py install

 Installation of IOUYAP

$ sudo dnf install gcc flex bison glibc-devel iniparser-devel

Some packages may already be installed and will be skipped.

$ bison --yacc -dv netmap_parse.y<br />
$ flex netmap_scan.l<br />
$ gcc -Wall -g *.c -o iouyap -liniparser -lpthread

At this point there is the VPCs, to configure but as I’m not intending on using that right now, I shall leave that for another day.