Introduction

The purpose of this exercise is to learn how to configure IS-IS between the Border and Core routers so that they exchange network reachability information and maintain their own routing tables dynamically.

In the last lab we configured some static routes to forward packets between the Border and Core routers. While it’s possible to run the network like this it can be difficult to keep the static routes up to date as your network changes.

Make sure to take the examples and adapt them to your own router, network topology and addressing scheme.

Lab Layout

As a reminder, 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.

The following table shows the connections between each device in the campus:

Replace Y with your building number and X with your campus number.

Accessing the Lab

The Workshop Instructors will let you know 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 you:

VIRTUAL ENVIRONMENT: Virtual Environment Lab Access Instructions

PHYSICAL HARDWARE: Physical Hardware Lab Access Instructions

Summary Commands

During all exercises, verify the output of the following commands:

show arp                 : Shows ARP cache
show interface <int>     : Shows interface state and configuration
show ip interface        : Shows interface IPv4 state and configuration
show ipv6 interface      : Shows interface IPv6 state and configuration
show run interface <int> : Shows the configuration of the interface

Dynamic Routing with IS-IS

We will now prepare the border and core router to introduce IS-IS to them. We will be replacing the static routes we configured earlier with IS-IS, where the routes on each router are announced to their neighbour. In future this will mean that we do not need to introduce a static route when we introduce new subnets in our campus.

Loopback Interface

First of all we will set up a Loopback interface on both routers. It is industry convention and best practice to create a Loopback interface on all L3 devices, for various reasons. Remember to change X to your group number.

On the Border router:

interface Loopback0
 ip address 100.68.X.241 255.255.255.255
 ipv6 address 2001:DB8:X:2::241/128
!

On the Core router:

interface Loopback0
 ip address 100.68.X.242 255.255.255.255
 ipv6 address 2001:DB8:X:2::242/128
!

Setting up the IS-IS routing process

We now create the basic IS-IS process.

Recall from the IS-IS presentation that there were two suggested ways of configuring an NET address. We will use the alternative and simpler method here¹, namely 49.0001.group.loop.00. For example, the border router (loopback 100.68.2.242) in Group 2 would have an NET address of 49.0001.0002.0242.00.

Enable multi-topology for our dual stack network, set the modern wide metrics, and use a default metric of 100000 for both IPv4 and IPv6. Also, we change Cisco’s default of L1-L2 operation to be L2 only.

On the Border router: (As usual, change X to your group number)

router isis campusX
 net 49.0001.000X.0241.00
 is-type level-2-only
 metric-style wide
 log-adjacency-changes all
 metric 100000
 !
 address-family ipv6
  multi-topology
  metric 100000
!

On the Core router:

router isis campusX
 net 49.0001.000X.0242.00
 is-type level-2-only
 metric-style wide
 log-adjacency-changes all
 metric 100000
 !
 address-family ipv6
  multi-topology
  metric 100000
!

Note: campusX is the IS-IS process tag, which identifies the IS-IS routing process within the router. It can be any string, or omitted entirely, but whatever you choose needs to be consistent within a given router. (Some operators use their Autonomous System Number as the tag).

Create the authentication key chain

As we will be using neighbour authentication as discussed in the IS-IS presentation, next we create the authentication key-chain. “isis-key” is a label for the key, and “cndlab123” is the actual secret value.

key chain isis-key
 key 1
  key-string cndlab123
!

Add in IS-IS authentication

The authentication is added in to the IS-IS process, being applied to every interface enabled for IS-IS.

router isis campusX
 authentication mode md5 level-2
 authentication key-chain isis-key level-2
!

Announce the Loopback interface addresses

We need to announce the IPv4 and IPv6 Loopback interface addresses. The easiest way of doing this is just making that interface as “passive” in IS-IS - this is designed to announce the interface addresses without running IS-IS on the interface.

router isis campusX
 passive-interface loopback0
!

Adding the IS-IS process to interfaces

We will now configure IS-IS on the interfaces where adjacencies need to be established. We activate both IPv4 and IPv6 adjacencies.

The interface metric on all interfaces is set to “2”, done for both IPv4 and IPv6. Note that each ethernet interface is declared to be point-to-point - even though they are broadcast interfaces, there are only two devices so we do not need the DIS selection as with normal broadcast media.

On the Border router:

interface GigabitEthernet0/1
 ip router isis campusX
 isis metric 2
 isis network point-to-point
 ipv6 router isis campusX
 isis ipv6 metric 2
!

On the Core router:

interface GigabitEthernet0/0
 ip router isis campusX
 isis metric 2
 isis network point-to-point
 ipv6 router isis campusX
 isis ipv6 metric 2
!

STOP - Checkpoint.

show isis protocol       : shows general IS-IS information
show isis neighbor       : show adjacencies
show isis ip topology    : show IP paths to other IS-IS routers
show ip route            : show all routes in main RIB
show ip route isis       : show only IS-IS routes
show isis ip unicast rib : shows the IS-IS Routing Information Base (RIB)

The status commands for IPv6 are very similar: simply replace “ip” in the above show commands with “ipv6”.

Question: When you run show isis ip unicast rib on the Border router, do you see the subnets for the VLANs downstream of the Core router, e.g. the staff and student VLANs?

Answer: You won’t see these yet. You need to tell the Core router to announce those subnets in IS-IS - without actually sending any IS-IS packets on those interfaces. That is, you need passive-interface again.

On the Core:

router isis campusX
 passive-interface vlan10
 passive-interface vlan11
 passive-interface vlan12
 passive-interface vlan20
 passive-interface vlan21
 passive-interface vlan22
 passive-interface GigabitEthernet0/3
!

Now you should see them on the border.  

Originating a Default Route from Border Router

We now will use IS-IS to announce a default route into the core network. This will replace the static default route currently in use. To do this, we use the following commands.

On the border router:

router isis campusX
 default-information originate
 !
 address-family ipv6
  default-information originate
!

This will originate a default route into IS-IS (which means that it will be distributed to IS-IS neighbours) as long as a default route exists in the router’s Global RIB. The default is already in the Border Router Global RIB because of the static default route we set up in the Static Routing Lab exercise.

Check the IS-IS RIB on the Core Router to make sure you see the default there. On the Core Router, do:

show isis ip unicast rib
show isis ipv6 unicast rib

You should see the default route for IPv4 (0.0.0.0/0) and IPv6 (::/0) in the IS-IS RIB using the above commands.

Once the Border router is announcing the default route by IS-IS, you can remove the static default route on the Core router using:

no ip route 0.0.0.0 0.0.0.0 100.68.X.1
no ipv6 route ::/0 2001:DB8:X::1

Check that routing to the other groups is still working using:

show ip route
show ipv6 route

You should see the default route in the table as an IS-IS level-2 (i L2) announcement. There should now be no static routes remaining in the core router.

Removing Static Routes

The IS-IS Lab is normally conducted after completing the static routing exercise. There still will be lots of static routes on the border so it can reach the other networks.

We will now remove these static routes, carefully.

The Border router can now remove the static routes pointing to the Core Router for each of the Staff, Student and Management vLANs. These routes are now learned by IS-IS from the Core router. Here is the configuration example:

no ip route 100.68.X.128 255.255.255.240 100.68.X.2
no ip route 172.2X.10.0 255.255.255.0 100.68.X.2
no ip route 172.2X.11.0 255.255.255.0 100.68.X.2
no ip route 172.2X.12.0 255.255.255.0 100.68.X.2
no ip route 172.2X.20.0 255.255.255.0 100.68.X.2
no ip route 172.2X.21.0 255.255.255.0 100.68.X.2
no ip route 172.2X.22.0 255.255.255.0 100.68.X.2
!
no ipv6 route 2001:DB8:X:1::/64 2001:DB8:X:0::2
no ipv6 route 2001:DB8:X:10::/64 2001:DB8:X:0::2
no ipv6 route 2001:DB8:X:11::/64 2001:DB8:X:0::2
no ipv6 route 2001:DB8:X:12::/64 2001:DB8:X:0::2
no ipv6 route 2001:DB8:X:20::/64 2001:DB8:X:0::2
no ipv6 route 2001:DB8:X:21::/64 2001:DB8:X:0::2
no ipv6 route 2001:DB8:X:22::/64 2001:DB8:X:0::2

To finish off, all teams should now check the Routing Table. Document the output of:

show ip route
show ipv6 route

and be prepared to show this to the workshop instructors. The group network is now using a dynamic routing protocol to share routing information within the group - a much more scalable solution than the effort that was required to set up the static routes in the previous lab exercise.

Dropping packets for networks that are not in use

We are only using some of the subnets in our network address allocation. If we receive packets from outside our network at the Border router to these ranges:

100.68.X.0/24
172.2X.0.0/16
2001:DB8:X::/48

we should never forward packets to the Core router unless we have learnt a route for a subnet. For example, what should we do with a packet addressed to 100.68.X.67?

On the Border router try running the show ip route command - you should see something like in the example below:

bdr1.campus1#show ip route 100.68.1.67
% Subnet not in table

The only entry in the routing table that matches this address is the default route².

Also, on the Core router, what do we do with a packet addressed to 172.2X.55.128 that might have come from one of the campus devices connected to the Access switches? This is part of the 172.2X.0.0/16 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 172.21.55.128
% Subnet not in table

and then:

core1.campus1#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "isis", distance 115, metric 2, candidate default path, type level-2
  Redistributing via isis campus1
  Last update from 100.68.1.1 on GigabitEthernet0/0, 00:05:54 ago
  Routing Descriptor Blocks:
  * 100.68.1.1, from 100.68.1.241, 00:05:54 ago, via GigabitEthernet0/0
      Route metric is 2, traffic share count is 1

You’ll note that the specific destination is not in the Core router’s routing table; but we have a default route, learned from IS-IS, and so traffic to 172.21.55.128 will be sent to the Border router and on out to the Internet following the default route to the NREN.

It’s good practice to have routes in place that drop traffic like this. We do this on both the Border and Core routers using:

ip route 100.68.X.0 255.255.255.0 Null0
ip route 172.2X.0.0 255.255.0.0 Null0
ipv6 route 2001:DB8:X::/48 Null0

The more specific routes we learn on the Border and Core routers via IS-IS make sure that only traffic for networks that are in use are sent to the other router.

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
!

Final Checks

Check the routing table you see on both the border and core routers now. Do you have full Internet connectivity for IPv4 - check by trying to ping or traceroute to 8.8.8.8. If you have followed the steps above you’d have migrated your campus from static routes to dynamic routing using IS-IS without any break in connectivity.

Here is an example of the routing table from the Border router in campus1 from a previous Campus Network Design Workshop:

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 100.68.0.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 100.68.0.1
      100.0.0.0/8 is variably subnetted, 8 subnets, 4 masks
C        100.68.0.0/30 is directly connected, GigabitEthernet0/0
L        100.68.0.2/32 is directly connected, GigabitEthernet0/0
S        100.68.1.0/24 is directly connected, Null0
C        100.68.1.0/28 is directly connected, GigabitEthernet0/1
L        100.68.1.1/32 is directly connected, GigabitEthernet0/1
i L2     100.68.1.128/28 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1
C        100.68.1.241/32 is directly connected, Loopback0
i L2     100.68.1.242/32 [115/2] via 100.68.1.2, 00:22:31, GigabitEthernet0/1
      172.21.0.0/16 is variably subnetted, 7 subnets, 2 masks
S        172.21.0.0/16 is directly connected, Null0
i L2     172.21.10.0/24 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1
i L2     172.21.11.0/24 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1
i L2     172.21.12.0/24 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1
i L2     172.21.20.0/24 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1
i L2     172.21.21.0/24 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1
i L2     172.21.22.0/24 [115/2] via 100.68.1.2, 00:02:14, GigabitEthernet0/1

How well does this compare with what you see?

What about IPv6?

APPENDIX: OSPF configuration

Some vendors do not support IS-IS. An alternative is to use OSPF, which is actually two separate protocols: OSPFv2 for IPv4, and OSPFv3 for IPv6.

For reference, here are the configuration commands which would be used, from the point of view of the border router:

router ospf 41
 router-id 100.68.X.241
 log-adjacency-changes detail
 passive-interface default
 no passive-interface GigabitEthernet0/1
!
ipv6 router ospf 41
 router-id 100.68.X.241
 log-adjacency-changes detail
 passive-interface default
 no passive-interface GigabitEthernet0/1
!
interface Loopback0
 ip ospf 41 area 0
 ipv6 ospf 41 area 0
!
interface GigabitEthernet0/1
 ip ospf 41 area 0
 ipv6 ospf 41 area 0
!
router ospf 41
 default-information originate
!
ipv6 router ospf 41
 default-information originate
!

“41” is a process identifier. It can be any number you want, and is entirely internal to the router. Some operators use their AS number here.

In OSPF, “passive interface” means “do not send OSPF hello messages”, but unlike IS-IS it does not announce the subnet to other routers. Instead you add ip ospf and ipv6 ospf on all interfaces whose subnets you want to advertise - passive or not.

Here are the commands to check status:

show ip ospf             : shows general OSPF information
show ip ospf neighbor    : show adjacencies
show ip route            : show all routes in main RIB
show ip route ospf       : show only OSPF routes
show ip ospf rib         : shows the OSPF Routing Information Base (RIB)
show ip ospf interface   : shows the status of OSPF in an interface

In our lab environment, the IOSvL2 image we use for the core router supports OSPFv2 but not OSPFv3, so it will not work for IPv6.