The devices being used in this chapter are a bit different from the previous chapters. In the previous chapters, we were isolating a particular device by focusing on the topic at hand. For this chapter, we will use a few more devices in our lab in order to illustrate the function of the tools that we will be using. The connectivity and operating system information are important as they have ramifications regarding the security tools that we will show later in this chapter. For example, if we want to apply an access list to protect the server, we need to know what the topology looks like and which direction the client is making their connections from. The Ubuntu host connections are a bit different than what we have seen so far, so please make reference back to this lab section when you see the example later if needed. 

We will be using the same Cisco VIRL tool with four nodes: two hosts and two network devices. If you need a refresher on Cisco VIRL, feel free to go back to Chapter 2, Low-Level Network Device Interactions, where we first introduced the tool:

As illustrated, we will rename the host on the top as the client and the bottom host as the server. This is analogous to an internet client trying to access a corporate server within our network. We will again use the Shared flat network option for the management network to access the devices for the out-of-band management:

For the two switches, I will choose Open Shortest Path First (OSPF) as IGP and put both the devices in area 0. By default, BGP is turned on and both the devices are using AS 1. From the configuration auto generation, the interfaces connected to the Ubuntu hosts are put into OSPF area 1, so they will show up as inter-area routes. The NX-OSv configurations are shown here and the IOSv configuration and output are similar:

    interface Ethernet2/1
     description to iosv-1
      no switchport
      mac-address fa16.3e00.0001
      ip address 10.0.0.6/30
      ip router ospf 1 area 0.0.0.0
      no shutdown

    interface Ethernet2/2
      description to Client
      no switchport
      mac-address fa16.3e00.0002
      ip address 10.0.0.9/30
      ip router ospf 1 area 0.0.0.0
      no shutdown

    nx-osv-1# sh ip route
    <skip>
    10.0.0.12/30, ubest/mbest: 1/0
     *via 10.0.0.5, Eth2/1, [110/41], 04:53:02, ospf-1, intra
    192.168.0.2/32, ubest/mbest: 1/0
     *via 10.0.0.5, Eth2/1, [110/41], 04:53:02, ospf-1, intra
    <skip>

The OSPF neighbor and the BGP output for NX-OSv are shown here, and the IOSv output is similar:

nx-osv-1# sh ip ospf neighbors
 OSPF Process ID 1 VRF default
 Total number of neighbors: 1
 Neighbor ID Pri State Up Time Address Interface
 192.168.0.2 1 FULL/DR 04:53:00 10.0.0.5 Eth2/1

nx-osv-1# sh ip bgp summary
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 192.168.0.1, local AS number 1
BGP table version is 5, IPv4 Unicast config peers 1, capable peers 1
2 network entries and 2 paths using 288 bytes of memory
BGP attribute entries [2/288], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.0.2 4 1 321 297 5 0 0 04:52:56 1

The hosts in our network are running Ubuntu 14.04, similar to the Ubuntu VM 16.04 that we have been using up to this point:

cisco@Server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty

On both of the Ubuntu hosts, there are two network interfaces, eth0 and eth1. eth0 connects to the management network (172.16.1.0/24) while eth1 connects to the network devices (10.0.0.x/30). The routes to the device loopback are directly connected to the network block, and the remote host network is statically routed to eth1 with the default route going toward the management network:

cisco@Client:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.1.2 0.0.0.0 UG 0 0 0 eth0
10.0.0.4 10.0.0.9 255.255.255.252 UG 0 0 0 eth1
10.0.0.8 0.0.0.0 255.255.255.252 U 0 0 0 eth1
10.0.0.8 10.0.0.9 255.255.255.248 UG 0 0 0 eth1
172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.1 10.0.0.9 255.255.255.255 UGH 0 0 0 eth1
192.168.0.2 10.0.0.9 255.255.255.255 UGH 0 0 0 eth1

To verify the client-to-server path, let's ping and trace the route to make sure that traffic between our hosts is going through the network devices instead of the default route:

## Our server IP is 10.0.0.14
cisco@Server:~$ ifconfig
<skip>
eth1 Link encap:Ethernet HWaddr fa:16:3e:d6:83:02
 inet addr:10.0.0.14 Bcast:10.0.0.15 Mask:255.255.255.252

## From the client ping toward server
cisco@Client:~$ ping -c 1 10.0.0.14
PING 10.0.0.14 (10.0.0.14) 56(84) bytes of data.
64 bytes from 10.0.0.14: icmp_seq=1 ttl=62 time=6.22 ms

--- 10.0.0.14 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.223/6.223/6.223/0.000 ms

## Traceroute from client to server
cisco@Client:~$ traceroute 10.0.0.14
traceroute to 10.0.0.14 (10.0.0.14), 30 hops max, 60 byte packets
 1 10.0.0.9 (10.0.0.9) 11.335 ms 11.745 ms 12.113 ms
 2 10.0.0.5 (10.0.0.5) 24.221 ms 41.635 ms 41.638 ms
 3 10.0.0.14 (10.0.0.14) 37.916 ms 38.275 ms 38.588 ms
cisco@Client:~$

Great! We have our lab; we are now ready to look at some security tools and measures using Python.