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.
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
$ORIGIN 20.168.192.in-addr.arpa.
$TTL 1d
@    IN    SOA    ns.lab.tobyheywood.com.    hostmaster.lab.tobyheywood.com. (
2016022400    ; Serial
6h        ; Refresh
1h        ; Retry
2d        ; Expire
1d )        ; Minimum TTL
;
@    IN    NS    ns.lab.tobyheywood.com.
;
1    IN    PTR    rhc-server.lab.tobyheywood.com.

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
options {
listen-on port 53 { 192.168.20.1; };
//listen-on-v6 port 53 { ::1; };
directory     "/var/named";
dump-file     "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query     { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "lab.tobyheywood.com" IN {
type master;
file "data/lab.tobyheywood.com";
allow-update { none; };
};

zone "20.168.192.in-addr.arpa" IN {
type master;
file "data/lab.tobyheywood.com.rr.zone";
allow-update { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

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

; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> -x 192.168.20.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45831
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1.20.168.192.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
1.20.168.192.in-addr.arpa. 86400 IN    PTR    rhc-server.lab.tobyheywood.com.

;; AUTHORITY SECTION:
20.168.192.in-addr.arpa. 86400    IN    NS    ns.lab.tobyheywood.com.

;; ADDITIONAL SECTION:
ns.lab.tobyheywood.com.    86400    IN    A    192.168.20.1

;; Query time: 0 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Wed Feb 24 23:20:47 GMT 2016
;; MSG SIZE  rcvd: 131

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

Back to basics – Setting a DHCP server

Posted on Leave a commentPosted in CentOS 7, DHCP, Linux, Networking, System Administration

Following on from other posts in the “back to basics” series; Local yum repository and setting up an internal DNS server. Here is the next step in the process of building a infrastructure services server.

So we have DNS in place and working.  Now lets make sure that none of the client machines in the lab have to be configured with an IPv4 address manually.

First things first, lets get dhcp installed;

[root@rhc-server etc]# yum install dhcp -y

Before I look to configure DHCP for my needs, lets just have a quick look at the example configuration file.  This is good for a number of reasons, sometimes you will see certain options being used which you would not have used if it weren’t for having seen them in an example.

[root@rhc-server etc]# cat /usr/share/doc/dhcp*/dhcpd.conf.example
# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

subnet 10.152.187.0 netmask 255.255.255.0 {
}

# This is a very basic subnet declaration.

subnet 10.254.239.0 netmask 255.255.255.224 {
range 10.254.239.10 10.254.239.20;
option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

subnet 10.254.239.32 netmask 255.255.255.224 {
range dynamic-bootp 10.254.239.40 10.254.239.60;
option broadcast-address 10.254.239.31;
option routers rtr-239-32-1.example.org;
}

# A slightly different configuration for an internal subnet.
subnet 10.5.5.0 netmask 255.255.255.224 {
range 10.5.5.26 10.5.5.30;
option domain-name-servers ns1.internal.example.org;
option domain-name "internal.example.org";
option routers 10.5.5.1;
option broadcast-address 10.5.5.31;
default-lease-time 600;
max-lease-time 7200;
}

# Hosts which require special configuration options can be listed in
# host statements.&nbsp;&nbsp; If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

host passacaglia {
hardware ethernet 0:0:c0:5d:bd:95;
filename "vmunix.passacaglia";
server-name "toccata.fugue.com";
}

# Fixed IP addresses can also be specified for hosts.&nbsp;&nbsp; These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.&nbsp;&nbsp; Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
host fantasia {
hardware ethernet 08:00:07:26:c0:a5;
fixed-address fantasia.fugue.com;
}

# You can declare a class of clients and then do address allocation
# based on that.&nbsp;&nbsp; The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

class "foo" {
match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
}

shared-network 224-29 {
subnet 10.17.224.0 netmask 255.255.255.0 {
option routers rtr-224.example.org;
}
subnet 10.0.29.0 netmask 255.255.255.0 {
option routers rtr-29.example.org;
}
pool {
allow members of "foo";
range 10.17.224.10 10.17.224.250;
}
pool {
deny members of "foo";
range 10.0.29.10 10.0.29.230;
}
}

As we can see from the above, the examples have provided us with pretty much everything we need to know and more to get things up and running.  Below is the configuration file that I created;

[root@rhc-server dhcp]# cat dhcpd.conf
#
#&nbsp; lab.tobyheywood.com dhcp daemon configuration file
#
#&nbsp; 2016-02-22 - Initial creation
#

# Define which IP to listen on.&nbsp; NOTE. daemon can only listen to one
# IP at a time if defined.
local-address 192.168.20.1;

# option definitions common to all supported networks...
option domain-name "lab.tobyheywood.com";
option domain-name-servers ns.lab.tobyheywood.com;

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style interim;

# This is the authoritative DHCP server.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# My management network on a separate interface
# Included in configuration otherwise I get errors in journalctl
# **** NOT IN USE ****
subnet 192.168.122.0 netmask 255.255.255.0 {
}

# The lab network
subnet 192.168.20.0 netmask 255.255.255.128 {
range 192.168.20.50 192.168.20.99;
option routers rtr.lab.tobyheywood.com;
}

Hopefully the comments above are sufficient to give you a good idea of what each bit is therefore and what it does.

Now lets start the dhcpd daemon and check everything is working as it should.

[root@rhc-server dhcp]# systemctl enable dhcpd
[root@rhc-server dhcp]# systemctl start dhcpd
[root@rhc-server dhcp]# systemctl list-units | grep named
named.service        loaded active running     Berkeley Internet Name Domain (DNS)
[root@rhc-server dhcp]# systemctl list-units | grep -e dhcpd
dhcpd.service        loaded active running     DHCPv4 Server Daemonctl

And a quick review of the logs shows we are cooking with gas!

Feb 22 22:11:13 rhc-server systemd[1]: Starting DHCPv4 Server Daemon...
Feb 22 22:11:13 rhc-server systemd[1]: Started DHCPv4 Server Daemon.
Feb 22 22:11:13 rhc-server dhcpd[3145]: Internet Systems Consortium DHCP Server 4.2.5
Feb 22 22:11:13 rhc-server dhcpd[3145]: Copyright 2004-2013 Internet Systems Consortium.
Feb 22 22:11:13 rhc-server dhcpd[3145]: All rights reserved.
Feb 22 22:11:13 rhc-server dhcpd[3145]: For info, please visit https://www.isc.org/software/dhcp/
Feb 22 22:11:13 rhc-server dhcpd[3145]: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the...ig file
Feb 22 22:11:13 rhc-server dhcpd[3145]: Internet Systems Consortium DHCP Server 4.2.5
Feb 22 22:11:13 rhc-server dhcpd[3145]: Copyright 2004-2013 Internet Systems Consortium.
Feb 22 22:11:13 rhc-server dhcpd[3145]: All rights reserved.
Feb 22 22:11:13 rhc-server dhcpd[3145]: For info, please visit https://www.isc.org/software/dhcp/
Feb 22 22:11:13 rhc-server dhcpd[3145]: Wrote 1 leases to leases file.
Feb 22 22:11:13 rhc-server dhcpd[3145]: Listening on LPF/ens8/52:54:00:ca:b3:a6/192.168.20.0/25
Feb 22 22:11:13 rhc-server dhcpd[3145]: Sending on&nbsp;&nbsp; LPF/ens8/52:54:00:ca:b3:a6/192.168.20.0/25
Feb 22 22:11:13 rhc-server dhcpd[3145]: Listening on LPF/ens3/52:54:00:2b:da:2b/192.168.122.0/24
Feb 22 22:11:13 rhc-server dhcpd[3145]: Sending on&nbsp;&nbsp; LPF/ens3/52:54:00:2b:da:2b/192.168.122.0/24
Feb 22 22:11:13 rhc-server dhcpd[3145]: Sending on&nbsp;&nbsp; Socket/fallback/fallback-net
Feb 22 22:13:35 rhc-server dhcpd[3145]: DHCPDISCOVER from 52:54:00:a6:a4:fa via ens8
Feb 22 22:13:35 rhc-server dhcpd[2682]: DHCPDISCOVER from 52:54:00:a6:a4:fa via ens8
Feb 22 22:13:36 rhc-server dhcpd[3145]: DHCPOFFER on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:36 rhc-server dhcpd[2682]: ns.lab.tobyheywood.com: host unknown.
Feb 22 22:13:36 rhc-server dhcpd[2682]: rtr.lab.tobyheywood.com: host unknown.
Feb 22 22:13:36 rhc-server dhcpd[2682]: DHCPOFFER on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[3145]: DHCPREQUEST for 192.168.20.50 (192.168.20.1) from 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[3145]: DHCPACK on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[2682]: DHCPREQUEST for 192.168.20.50 (192.168.20.1) from 52:54:00:a6:a4:fa (rhc-client) via ens8
Feb 22 22:13:37 rhc-server dhcpd[2682]: DHCPACK on 192.168.20.50 to 52:54:00:a6:a4:fa (rhc-client) via ens8

So with the exception of the two “host unknown” errors we are looking good!  So that will do for now.

Time to go investigate the host unknown issue, ggrrrrrr!  Can I ping it? Yes I can!

Back to basics – Setting up a local (internal) DNS server

Posted on Leave a commentPosted in CentOS 7, DNS, Linux, RHEL 7, System Administration

Today’s “back to basics” post is all about setting up a local internal DNS server. Though there are a number of applications out there which will ease the process of setting up DNS and/or DHCP services, I am sticking with what would be used in the enterprise environment and also focusing on doing things manually.

Why manually?? Well, it has been a while since I’ve had to configure named from scratch and so it’s good to remind me how it all fits together. Plus, by knowing how the internals are working (as far as the configuration is concerned) it means if I run into problems, then I’m better placed to fix the issue sooner and with less searching.

So for DNS that would be (IMHO) BIND.  BIND has been around for a very long time and for those of you with an interest in it’s history, take a look at; BIND – Wikipedia.  In CentOS and RHEL you have two options the base BIND packages or an additional package which configures BIND to run in a chroot jail.

Because I am only setting this up for the purpose of a lab, I will not be making use of the chroot version (though in all honesty it doesn’t require much additional effort) and will stick
instead with the base package.  HOWEVER, IF you are going to use BIND on a server which has a public facing interface onto the big
, bad Internet, then without doubt, MAKE SURE YOU USE THE CHROOT package too.  There is no reason not to in my opinion!

Back to the lab installation


[root@rhc-server ~]# yum install bind -y
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package bind.x86_64 32:9.9.4-14.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================
Package                     Arch                          Version                                   Repository                        Size
============================================================================================================================================
Installing:
bind                        x86_64                        32:9.9.4-14.el7                           baselocal                        1.8 M

Transaction Summary
============================================================================================================================================
Install  1 Package

Total download size: 1.8 M
Installed size: 4.3 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : 32:bind-9.9.4-14.el7.x86_64                                                                                              1/1
Verifying  : 32:bind-9.9.4-14.el7.x86_64                                                                                              1/1

Installed:
bind.x86_64 32:9.9.4-14.el7

Complete!

OK, so now we have it installed we need to create a zone file which will contain all of our required internal DNS zone information.  Zone files are stored in the /var/named/data directory (or if using chroot version of bind /var/named/chroot/var/named/data).  As you can see currently there are no zone files in this location;


[root@rhc-server data]# pwd
/var/named/data
[root@rhc-server data]# ls
[root@rhc-server data]#

For my internal DNS I’m going setting up a zone called “lab.tobyheywood.com” and the zone file looks more or less as follows;


[root@rhc-server data]# cat lab.tobyheywood.com
$TTL 1d
@        IN    SOA    ns.lab.tobyheywood.com.    hostmaster.lab.tobyheywood.com. (
2016022100    ; Serial
1h        ; Refresh
15m        ; Retry
10d        ; Expire (10 days should be enough in the lab)
1h )        ; Negative Cache
;
; Name Servers
IN    NS    ns.lab.tobyheywood.com.
;
; MX Records (Mail eXchange)
;
; CNAME (Canonical Name a.k.a. Aliases)
provision    IN    CNAME    ns.lab.tobyheywood.com.
;
; A Records (IPv4 addresses)
ns        IN    A    192.168.20.1
rhc-server    IN    A    192.168.20.1

;
; AAAA Records (IPv6 Records)
; - Not used yet but at a later stage in the lab

As you can probably spot, I am using the IPv4 address 192.168.20.1 as the primary IP address for my server.

The next step is to updated the /etc/named.conf file so that it is listening on the right ip address and also to define the zone I have just created.

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
listen-on port 53 { 192.168.20.1; };
//listen-on-v6 port 53 { ::1; };
directory     "/var/named";
dump-file     "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query     { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "lab.tobyheywood.com" IN {
type master;
file "data/lab.tobyheywood.com";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

To maintain a level of sanity, lets just do a couple of checks to make sure everything is, as it should be.


[root@rhc-server etc]# named-checkzone lab.tobyheywood.com /var/named/data/lab.tobyheywood.com
zone lab.tobyheywood.com/IN: loaded serial 2016022100
OK
[root@rhc-server etc]# named-checkconf
[root@rhc-server etc]# echo $?
0
[root@rhc-server etc]#

And now time to enable the service, start it and then test that I have got everything right.  Also as part of this step I have installed bind-utils so that I can confirm the zone is active by way of querying the name server.;


[root@rhc-server etc]# systemctl enable named
ln -s '/usr/lib/systemd/system/named.service' '/etc/systemd/system/multi-user.target.wants/named.service'
[root@rhc-server etc]# systemctl start named.service
[root@rhc-server etc]# yum install bind-utils -y
[root@rhc-server etc]# ping rhc-server.lab.tobyheywood.com -c 5
PING rhc-server.lab.tobyheywood.com (192.168.20.1) 56(84) bytes of data.
64 bytes from 192.168.20.1: icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=64 time=0.093 ms
64 bytes from 192.168.20.1: icmp_seq=3 ttl=64 time=0.091 ms
64 bytes from 192.168.20.1: icmp_seq=4 ttl=64 time=0.053 ms
64 bytes from 192.168.20.1: icmp_seq=5 ttl=64 time=0.093 ms

--- rhc-server.lab.tobyheywood.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.021/0.070/0.093/0.029 ms
[root@rhc-server etc]# dig ns.lab.tobyheywood.com

; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> ns.lab.tobyheywood.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56872
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns.lab.tobyheywood.com.        IN    A

;; ANSWER SECTION:
ns.lab.tobyheywood.com.    86400    IN    A    192.168.20.1

;; AUTHORITY SECTION:
lab.tobyheywood.com.    86400    IN    NS    ns.lab.tobyheywood.com.

;; Query time: 0 msec
;; SERVER: 192.168.20.1#53(192.168.20.1)
;; WHEN: Sun Feb 21 18:50:48 GMT 2016
;; MSG SIZE  rcvd: 81

The only thing that I had done ahead of time was to make sure that my /etc/resolv.conf file was updated to reflect the correct search and nameserver parameters.  So all in all looking good.

Till next time.

UPDATE!!!!

Err, well.  That’s embarrassing!  So as part of the above post though it work, somethings will not.  More specifically, if you try to perform a reverse look up it will fail miserably.  So to complete the picture, you can see what I did with regards the reverse zone here.

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
$ tunctl -t tap0 -u toby
$ ifconfig tap0 10.0.1.10 netmask 255.255.255.0 up
$ 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
$ sudo ip addr add 10.0.0.10/255.255.255.0 dev tap1
$ sudo ip link set tap1 up
$ sudo firewall-cmd --zone=FedoraWorkstation --add-interface=tap1
$ sudo ip addr show tap1
11: tap1: <broadcast,multicast,up,lower_up> mtu 1500 qdisc fq_codel state UP group default qlen 500
link/ether 26:2b:e4:a0:54:ba brd ff:ff:ff:ff:ff:ff
inet 10.0.0.10/24 scope global tap1
valid_lft forever preferred_lft forever
inet6 fe80::242b:e4ff:fea0:54ba/64 scope link 
valid_lft forever preferred_lft forever

Configuring the interface on the Cisco router inside of GNS3

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

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
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=0.096 ms
64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=0.050 ms
64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=0.058 ms
64 bytes from 10.0.0.10: icmp_seq=5 ttl=64 time=0.103 ms

--- 10.0.0.10 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.050/0.082/0.103/0.023 ms
# ping -c 5 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=9.16 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=5.64 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=11.2 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=7.29 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=255 time=2.98 ms

--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 2.980/7.266/11.253/2.847 ms

router1#ping 10.0.0.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/9/12 ms

I do believe that about covers.

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:
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
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

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;

</pre>

$ cd /path/to/gns3_source/dynamips_extracted_folder
$ mkdir build
$ cd build
$ cmake ..
$ sudo make install

Installation of GNS3-GUI

<code class="bash plain"></code><code class="bash functions"></code><code class="bash plain"></code><code class="bash functions"></code>$ cd /path/to/gns3_source/gns3-gui
$ sudo python3 setup.py install

Installation of GNS3-Server

$ cd ../gns3-server-1.3.7/
$ 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
$ flex netmap_scan.l
$ 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.

HP BL460c Gen8 and the missing HBA

Posted on Leave a commentPosted in FCoE, Linux, RHEL 6, Storage, System Administration

Let me begin my tale of woe by setting the scene appropriately;

  • 4x BL460cGen8
    • 2x Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz (10 Cores)
    • 128GB RAM
    • HPFlexFabric10Gb2-Port534FLB Adapter
      • in iLO (integrated Lights Out)
  • 4x c7000 enclosure (some platinum, some not)
    • OA (Onboard Administrator) firmware version: 4.30
    • VC (Virtual Connect) firmware version: 4.30
      • A server profile has been created for each server with the Ethernet connectivity and FCoE)
      • The server profile has also been assigned to the required bay (just putting this in so there is no doubt, it is set-up as it should be)
  • RHEL (Red Hat Enterprise Linux) 6.5 and 6.6 were tested
  • HP SPP (Service Pack for ProLiant) 2014.09.0(B) installed across the board and the RHEL 6.6 Supplemental for the SPP have been applied where required
    UPDATE – HP have release SPP 2015.04.0.

The tale of woe!

I had a new requirement to set-up 4 new servers which would run RHEL 6.6 and would very much rely upon SAN based storage.

Installing RHEL was the easy part, getting the server to see it had access to FCoE (Fibre Channel of Ethernet) was more tricky, but only because there is a marked difference between the implementation of FCoE when using a Broadcom CNA (Converged Network Adapter) vs Emulex or Qlogic.

Things I checked

  • lspci – Didn’t show anything Fibre related.
  • dmesg – Equally didn’t show anything HBA or SAN related.
  • looking in the /sys/class directory structure showed no signs of the fc_host I am accustomed too.
  • A quick reboot a trawl through the BIOS (in HP speak RBSU) also showed no signs of anything SAN related.
  • Googled the issue to death
  • Confirmed that the CNA definitely was SAN compatible (you never know)
  • Logged onto the SAN switches to confirm there was connectivity between the Virtual Connect modules and the switches (it was but it showed that no blades had attempted to log into the fabric)
  • In the end I logged a ticket with HP.

The solution

So… After much head banging, and three hours describing the issue to HP first line technical bods, plus submitting (what felt like in triplicate) numerous logs from OA, VC and the server, I was finally pointed to the following URLs;

Now the above guides are all well and good assuming you haven’t followed the advice by HP tech support to upgrade to the latest firmware/drivers.  If you have done exactly as they have asked (not the you usually have much choice in the matter), then the following guide proved more useful;

One word of warning.  In the first article (Broadcom-Based CNAs…) above, when you get to step 6, It states you should run the following command;

# lldptool set-lldp-i ethY adminStatus=disabled

There is a typo and the line should be entered at the command line (as root) as follows;

# lldptool set-lldp -i ethY adminStatus=disabled[/bash

With the above you will need to replace ethY with the actual interface name.

Also:  Its not made crystal clear but you will need to make sure that you update the ifcfg-ethY files for the NICs that are using the FCoE personality so that they are brought online at boot.

Going forward

For me, I have created a script to recreate this, so should we purchase servers with this card installed again, the set-up remains consistent and documented.  That said it is still very much a manual step to enable the FCoE personality on the card.

Online LUN expansion (Step-by-Step)

Posted on Leave a commentPosted in Linux, RHEL 6, RHEL 7, System Administration

As with many things in life, it is easy to outgrow the environment you find yourself in.  When looking a LUNs and using LVM we can easily accommodate resizing of the back end storage and transferring this through the to volume presented to your RHEL server.

Note. The following details presenting a brand new LUN to the server rather than trying to expand the existing underlying LUN, as I feel this is a safer option.

The following provides a rough guide to the steps require;

  • Create new LUN and export to server
  • Configure multipathing
  • Create partition and set it touseLVM
    • parted /dev/mapper/new_lun
    • parted> mklabel gpt
    • parted> mkpart new_name ext4 0% 100%
    • parted> set 1 lvm on
    • parted> q
  • Run pvcreate on raw device file /dev/mapper/whateverp1
  • Run vgextend vol_group pv_dev
  • Run pvmove old_pv_dev new_pv_dev (this step will take a long time if the LUN is huge)
  • Run vgreduce vg_name old_pv_dev
  • pvremove old_pv_dev
  • Run lvextend -l +100%FREE /dev/vol_group/logical_vol
  • Run resize2fs /dev/vol_group/logical_vol

If you now run `df -h` you should see the file system has grown to the size of the new LUN.