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.
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
load-interval 30
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
load-interval 30
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
load-interval 30
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
load-interval 30
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 WIRED and WIFI VLANs on the Core Router. Here is an example for VLAN 11, the WIRED VLAN in Building 1:
interface vlan 11
description Wired VLAN of Building 1
ip address 10.1.1.1 255.255.255.0
ipv6 address 2001:DB8:X:11::1/64
load-interval 30
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, 18, 21 and 28 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 10.1.1.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
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
C 10.1.0.0/24 is directly connected, Vlan10
L 10.1.0.1/32 is directly connected, Vlan10
C 10.1.1.0/24 is directly connected, Vlan11
L 10.1.1.1/32 is directly connected, Vlan11
C 10.1.8.0/21 is directly connected, Vlan18
L 10.1.8.1/32 is directly connected, Vlan18
C 10.2.0.0/24 is directly connected, Vlan20
L 10.2.0.1/32 is directly connected, Vlan20
C 10.2.1.0/24 is directly connected, Vlan21
L 10.2.1.1/32 is directly connected, Vlan21
C 10.2.8.0/21 is directly connected, Vlan28
L 10.2.8.1/32 is directly connected, Vlan28
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/3and 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 also have a number of subnets for the Network Monitoring and Management LAN and for VLANs 10, 11, 18, 20, 21 and 28. Your Border router needs to be able to send packets to those subnets. The easiest way is to point static routes for the campus’ public (IPv4 and IPv6) address space and all the internal address space (10.0.0.0/8) from the Border router to the Core router, like this:
ip route 100.68.X.0 255.255.255.0 100.68.X.2
ip route 10.0.0.0 255.0.0.0 100.68.X.2
ipv6 route 2001:DB8:X::/48 2001:DB8:X:0::2
The switches also need a default route added to them so that their NETMGMT 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 10.1.0.1
ipv6 route ::/0 2001:DB8:X:10::1For Building 2 try:
ip route 0.0.0.0 0.0.0.0 10.2.0.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.
If traceroute is not installed1 in the Ubuntu OS running on the system we will need to install it. We can do this by typing 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? Does the traceroute stop displaying anything after 2-3 hops? If it does, are you able to explain why?
Finally, go back to your srv1 system and try this snmpstatus command. Again, if it is not installed on the srv1 system, you’ll need to install it:
sudo apt install snmpThen you can run:
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: [10.x.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!
We are only using some of the subnets in our network address allocation. If we receive packets from outside our network to these ranges:
100.68.X.0/24
10.0.0.0/8
2001:DB8:X::/48we need to discard the packet unless we have a route for the appropriate subnet. For example, what should we do with a packet addressed to 100.68.X.67?
On the Core router try running the show ip route command - you should see something like in the example below:
core1-campus1#show ip route 100.68.1.67
% Subnet not in tableThe only entry in the routing table that matches this address is the default route2.
Also, what do we do with a packet addressed to 10.2.55.128 that might have come from one of the campus devices connected to the Access switches? This is part of the 10.0.0.0/8 address block we use for the internal campus network, but we don’t have a routing table entry for it, apart from the default route. Here is an example from the Core router of Campus 1:
core1-campus1#show ip route 10.2.55.128
% Subnet not in tableand then:
core1-campus1#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Routing Descriptor Blocks:
* 100.68.1.1
Route metric is 0, traffic share count is 1You’ll note that the specific destination is not in the Core router’s routing table; but we have a static default route, and so traffic to 10.2.55.128 will be sent to the Border router which will then send it back to the Core router.
It’s good practice to have routes in place that drop traffic like this. We do this on the Core router only using:
ip route 100.68.X.0 255.255.255.0 Null0
ip route 10.0.0.0 255.0.0.0 Null0
ipv6 route 2001:DB8:X::/48 Null0The more specific routes we have configured on the Core router makes sure that only traffic for networks that are in use are sent onwards.
And because we are now sending traffic destined for unannounced routes towards the Null interface, we need to set up the Null interface to not respond with ICMP unreachable messages for IPv4 and IPv6 (this is so that a stream of traffic to unannounced routes does not result in the router sending “unreachable” responses).
Add the following on both the Core and Border routers:
interface Null0
no ip unreachables
no ipv6 unreachables
!
Call an instructor and show them your working system. Show them the traceroutes from your core router and server system (srv1) out to the Internet.
Rather than using traceroute, the mtr command is installed by default, and gives similar but continuously updating output.↩︎
Because the only matching destination is the default route pointing to the Border router, the Core router will send any packets for 100.68.1.67 to the default route, the Border router. The Border router sees the destination is part of the Campus address block, so sends the packets to the Core router. And the cycle repeats, a looping packet consumes bandwidth and router CPU until the time to live expires. Best practice is to drop such traffic with a Null route.↩︎