The purpose of this lab is to now add Layer 3 functionality to our newly finished Layer 2 network. The Core Switch has basic L3 capability right now in that it is routing between the different VLANs configured on it. However, we now want to give the campus connectivity to the border router and onwards to the NREN and the Internet.
The class will continue in its 6 groups with each group being assigned one campus to configure; attention will now be turned to configuring routing on the border router and core router (which we have been calling a switch up to now).
The following diagram shows the layout of the devices and all the links for each campus:
Our campus network consists of two routers, bdr1.campusX and core1.campusX as well as six switches. We have already configured the distribution and edge switches, as well as completed the L2 configuration of the core router. We will not need to touch any of the L2 configuration any more.
The Workshop Instructors will have already told you what the lab environment is. It will either be run on a Virtual Platform, or on real physical switches provided in the Training Room.
Refer to the correct document below for information about logging into the devices that have been assigned to your group:
VIRTUAL ENVIRONMENT: Virtual Environment Lab Access Instructions
PHYSICAL HARDWARE: Physical Hardware Lab Access Instructions
As we saw when we set up the switches earlier on in the workshop, we have to apply basic initial configuration to our Border Router as well, before we configure any IP addresses or any routing on it. The following is what you need to do, exactly the same initial configuration you applied to the switches.
Before going to the static routing lab, apply the following configuration to the Border Router. If you don’t remember what some of the configuration does, please refer back to the L2 Setup Lab for a detailed explanation.
Note that more modern versions of Cisco’s IOS will use type 9 (scrypt) encryption for the username and enable secrets. Also note that for a persistent ifindex, the SNMP command used for a router is slightly different from what we used on the switches.
hostname bdr1.campusX
!
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
!
aaa new-model
aaa authentication login default local
aaa authentication enable default enable
!
username cndlab algorithm-type scrypt secret lab-PW
enable algorithm-type scrypt secret lab-EN
service password-encryption
!
no ip domain lookup
ip domain name ws.nsrc.org
!
no logging console
logging buffered 8192 debug
!
ip ssh version 2
crypto key generate rsa modulus 2048
!
snmp-server group ReadGroup v3 auth
snmp-server user admin ReadGroup v3 auth sha NetManage
snmp-server location Campus Network Design Workshop
snmp-server ifindex persist
!
banner login ^
Campus Network Design and Operations Workshop Lab
Network Startup Resource Center
^
!
line con 0
transport preferred none
escape-character 3
exec-timeout 30 0
!
line aux 0
transport preferred none
escape-character 3
exec-timeout 30 0
!
line vty 0 4
transport preferred none
transport input ssh
escape-character 3
exec-timeout 30 0
!
Once you have applied the above template, remember to save the configuration using write mem.
The full address plan for the lab can be found in the IP Address Plan. Consult the address plan for the addresses of the point to point links between the Campus Border Router and the NREN Router.
Make sure you change the X and N below to the correct value from address plan mentioned above:
interface GigabitEthernet0/0
description Link to NREN
ip address 100.68.0.N 255.255.255.252
ipv6 address 2001:DB8:100:X::1/127
no ip redirects
no ip proxy-arp
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
no shutdown
!Test that you can ping the NREN end of the link.
Make sure you change the X below to the correct value for your campus:
interface GigabitEthernet0/1
description CAMPUS CORE
ip address 100.68.X.1 255.255.255.240
ipv6 address 2001:DB8:X:0::1/64
no ip redirects
no ip proxy-arp
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
no shutdown
!
We will now configure the interface on the Core Router connecting it to the Border Router. Since we will never carry multiple VLANs on this link, we can configure the port as a pure layer 3 (routed) interface, using the no switchport command.
Make sure you change the X below to the correct value for your campus:
interface GigabitEthernet0/0
description CAMPUS CORE to BORDER
no switchport
ip address 100.68.X.2 255.255.255.240
ipv6 address 2001:DB8:X:0::2/64
no ip redirects
no ip proxy-arp
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
no shutdown
!Test that you can ping your Border router at the other end this link.
Our network management and monitoring server, srv1.campusX.ws.nsrc.org, is connected to GigabitEthernet0/3 on the core router. We’ll configure the router, core1.campusX, so that we can start to use that server to manage and monitor our network. Again, since we are only routing a single subnet on this interface, we can configure the port as a routed interface using the no switchport command:
interface GigabitEthernet0/3
description Network Management and Monitoring
no switchport
ip address 100.68.X.129 255.255.255.240
ipv6 address 2001:DB8:X:1::1/64
no ip redirects
no ip proxy-arp
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
no shutdown
!Now connect to the console port of srv1 in your campus. Login as the “sysadm” user, with the password given to you by the workshop instructors.
From srv1, you should be able to ping the core router using the addresses you’ve just added to its GigabitEthernet0/3 interface:
ping 100.68.X.129
ping6 2001:DB8:X:1::1If that works, try using SSH to connect to the router.
ssh cndlab@100.68.X.129If this works, enter the router password to log in; then log out again. We are doing this just to verify connectivity; we will come back and make use of the network management and monitoring server later on in the workshop.
You might see an error like this:
Unable to negotiate with 100.68.X.129 port 22: no matching key exchange method found.
Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1This means the router only supports old cryptography algorithms which are disabled in newer versions of the SSH client (“sha1” is an insecure hash algorithm).
To fix this, create a new config file with an editor of your choice - we suggest using “nano” which is simple to use.
sudo nano /etc/ssh/ssh_config.d/cisco.confInsert the following content (changing ‘X’ as appropriate):
Host 100.68.X.129
KexAlgorithms +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
HostKeyAlgorithms +ssh-rsaThis configures the client to permit these older algorithms when talking to this device.
Then exit and save. (For nano: hit ctrl-X, then press “y” to confirm the save, then hit Enter to confirm the filename). Finally, try making the ssh connection again.
If your ssh connection hangs, and ctrl-C doesn’t break out, then use the SSH escape sequence (tilde ~ followed by a dot .) to disconnect. Then you can investigate what might have gone wrong.
We now configure the IP addresses of the STAFF and STUDENT VLANs on the Core Router. Here is an example for VLAN 11, the STAFF VLAN in Building 1:
interface vlan 11
description STAFF VLAN of Building 1
ip address 172.2X.11.1 255.255.255.0
ipv6 address 2001:DB8:X:11::1/64
no shutdown
!Replace X with your campus number. Do the same for all the other VLANs as well.
Once completed, your Core switch should have VLANs 11, 12, 21 and 22 configured with both IPv4 and IPv6 addresses.
Question: What is significant about the IP address configured on each VLAN?
Answer: This IP address now serves as the default gateway for every device connecting to this VLAN. So a user on VLAN 11 will have default gateway 172.2X.11.1, etc.
NB: This configuration only goes on the core switch, not the distribution and access switches.
At this stage you should be able to ping each of the devices in your campus network from their immediate neighbours. If you try to ping the Border router from one of the switches or the NMM server you’ll have less success. We need to add some additional routing information to the routers so that we can pass packets successfully.
Let’s look at the routing information on the Core router:
core1.campus1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
100.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 100.68.1.0/28 is directly connected, GigabitEthernet0/0
L 100.68.1.2/32 is directly connected, GigabitEthernet0/0
C 100.68.1.128/28 is directly connected, GigabitEthernet0/3
L 100.68.1.129/32 is directly connected, GigabitEthernet0/3
172.21.0.0/16 is variably subnetted, 12 subnets, 2 masks
C 172.21.10.0/24 is directly connected, Vlan10
L 172.21.10.1/32 is directly connected, Vlan10
C 172.21.11.0/24 is directly connected, Vlan11
L 172.21.11.1/32 is directly connected, Vlan11
C 172.21.12.0/24 is directly connected, Vlan12
L 172.21.12.1/32 is directly connected, Vlan12
C 172.21.20.0/24 is directly connected, Vlan20
L 172.21.20.1/32 is directly connected, Vlan20
C 172.21.21.0/24 is directly connected, Vlan21
L 172.21.21.1/32 is directly connected, Vlan21
C 172.21.22.0/24 is directly connected, Vlan22
L 172.21.22.1/32 is directly connected, Vlan22and on the Border router:
bdr1.campus1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
100.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C 100.68.0.0/30 is directly connected, GigabitEthernet0/0
L 100.68.0.2/32 is directly connected, GigabitEthernet0/0
C 100.68.1.0/28 is directly connected, GigabitEthernet0/1
L 100.68.1.1/32 is directly connected, GigabitEthernet0/1Each of the routers knows about the local and connected networks but no other routes.
What about IPv6? (Use show ipv6 route). What routes do you see for IPv6 destinations? Is there a similarity with what you see for IPv4?
Cisco IOS routers have IPv6 Routing turned off by default. So while we can reach our directly attached neighbours, we cannot get anywhere beyond, nor can we turn on any IPv6 routing protocols. We now need to turn on IPv6 routing, and to do that we use the following two commands:
ipv6 unicast-routing
ipv6 cef(IPv4 routing is of course already on by default. At some point in the future Cisco may well turn on IPv6 routing by default.)
The Core router needs a default route added to it so that we can forward traffic from the Campus network to the wider Internet via the NREN. We add this route to send traffic to the border router:
ip route 0.0.0.0 0.0.0.0 100.68.X.1
ipv6 route ::/0 2001:DB8:X:0::1
The Border router needs a default route added to it so that we can forward traffic from the Campus network to the wider Internet via the NREN. We add this route to send traffic to the NREN router:
ip route 0.0.0.0 0.0.0.0 100.68.0.N
ipv6 route ::/0 2001:DB8:100:X::0Choose the correct value for X and N from the IP address tables we used when we set up the interface.
You have also added a number of subnets on your core router and building switches for the Network Monitoring and Management subnet and for VLANs 10, 11, 12, 20, 21 and 22. Your Border router needs to be able to send packets to those subnets.
Here we are adding the static routes for Building 1’s VLANs pointing to the core router:
ip route 172.2X.10.0 255.255.255.0 100.68.X.2
ip route 172.2X.11.0 255.255.255.0 100.68.X.2
ip route 172.2X.12.0 255.255.255.0 100.68.X.2Do the same for Building 2 routes:
ip route 172.2X.20.0 255.255.255.0 100.68.X.2
ip route 172.2X.21.0 255.255.255.0 100.68.X.2
ip route 172.2X.22.0 255.255.255.0 100.68.X.2And now add the IPv6 static routes on the border router for Building 1:
ipv6 route 2001:DB8:X:10::/64 2001:DB8:X:0::2
ipv6 route 2001:DB8:X:11::/64 2001:DB8:X:0::2
ipv6 route 2001:DB8:X:12::/64 2001:DB8:X:0::2and for Building 2:
ipv6 route 2001:DB8:X:20::/64 2001:DB8:X:0::2
ipv6 route 2001:DB8:X:21::/64 2001:DB8:X:0::2
ipv6 route 2001:DB8:X:22::/64 2001:DB8:X:0::2Also add in the IPv4 and IPv6 static routes for the Server network:
ip route 100.68.X.128 255.255.255.240 100.68.X.2
ipv6 route 2001:DB8:X:1::/64 2001:DB8:X:0::2
The switches also need a default route added to them so that their MGMT VLAN can forward traffic to elsewhere in the network - without it, management traffic will only ever be able to reach other devices on their own VLAN.
On each switch we add this route to forward traffic to the Core router.
For Building 1 try:
ip route 0.0.0.0 0.0.0.0 172.2X.10.1
ipv6 route ::/0 2001:DB8:X:10::1For Building 2 try:
ip route 0.0.0.0 0.0.0.0 172.2X.20.1
ipv6 route ::/0 2001:DB8:X:20::1
We now verify the routing setup.
Now try pinging 8.8.8.8 from your Core router - does this work?
What about a traceroute to 8.8.8.8 from your Core router? What do you see?
Try logging into your srv1 system and running the same commands. Try ping first. Does this work?
If so, let’s try traceroute to 8.8.8.8 next. Note that traceroute is not installed1 by default in the Ubuntu OS running on the system so we need to install it - type the following commands at the command prompt on srv1:
sudo apt update
sudo apt install tracerouteOnce installed, run the traceroute command to 8.8.8.8. What do you see?
You should be able to see the trace go to your Border router, to the NREN router you connect to, to the lab gateway, and then on out to the Internet. The actual addresses (and names) will of course depend on the network operator’s infrastructure the lab has been connected to.
Now try pinging 2001:4860:4860::8888 from your Core router. Try a traceroute as well.
What happens? Can you explain why the traceroute stops displaying anything after 2-3 hops?
Finally, go back to your srv1 system and try this snmpstatus command. Note that you’ll need to install the command first:
sudo apt install snmpand then:
snmpstatus -v3 -l authNoPriv -u admin -a SHA -A NetManage x.x.x.xreplacing x.x.x.x with the IP address of the management interface of one of the campus devices. What do you see?
You should see something like the following:
[UDP: [172.2x.y.z]:161->[0.0.0.0]:35559]=>[Cisco IOS Software, vios_l2 Software (vios_l2-ADVENTERPRISEK9-M), Experimental Version 15.2(20200924:215240) [sweickge-sep24-2020-l2iol-release 135]
Copyright (c) 1986-2020 by Cisco Systems, Inc.
Compiled Tue 29-Sep-20 11:53 by sweickge] Up: 0:16:14.95
Interfaces: 0, Recv/Trans packets: 11058/10597 | IP: 3/2Try with all your campus devices.
This output shows that the response from one of the campus devices - and is another way of confirming that both the routing from your srv1 system to the management interfaces of the campus devices is working, and that the SNMP configuration you installed on each campus device during the setup of the workshop lab is actually working too!
Call an instructor and show them your working system.
Rather than using traceroute, the mtr command is installed by default, and gives similar but continuously updating output.↩