Welcome to the 4th article in this Cisco Configuration Professional series which will be presented, lab style. We will begin by listing the configuration tasks and then work through them together. We already familiarized ourselves with the CCP interface from the previous article.

Our network diagram will remain the same for now and we will add more devices as required as we continue in the series.

Configuration Tasks

  • Create a new loopback on RTR2 with IP address 22.22.22.22/32.
  • Allow only 1.1.1.1 to connect to RTR2 on that new Loopback interface.
  • Ensure that your connection does not break anything. Test your connections to ensure this.

Your entire configuration should be done through the Cisco Configuration Professional tool.

Configuration solutions

The first step is ensuring that our devices are discovered as shown below:

Task #1

Even though some of the interfaces on our GNS3 devices are not configurable via the CCP tool, loopbacks can be configured. To configure the loopback, we first select 2.2.2.2 as the community member.

I then click the Configure button and navigate to Interface Management > Interface and Connections > Edit Interface/Connection.

We can use the Add button to add a new logical interface. Notice that we can add GRE tunnels, Loopbacks or Virtual templates using this option.

The ‘Add a Loopback interface’ dialog box pops up as shown below.

By selecting ‘Static IP address’ from the IP address dropdown, we now have the option to configure the IP address and subnet mask for that interface. One of the cool things about the CCP tool is that it gives you the ability to use the /NN notation for the subnet mask portion as highlighted below.

After pressing OK, CCP shows you the equivalent CLI commands that will be sent to the device. You have the option of delivering it, canceling your configuration or saving it to a file. You can also select the option that the running configuration to be saved to startup configuration after the command is delivered.

This ‘Deliver Configuration to Device’ dialog box is very helpful because it shows you your GUI configurations turned into CLI commands. It’s a good way to learn. If however you don’t want this option, you can change it from the settings. Navigate to Application > Options.

You can then uncheck the ‘Show CLI preview’ option.

Back to our configuration, once the commands have been successfully delivered, you will see a ‘Commands Delivery Status’ dialog box like the one shown below.

Our interface has now been added to the list of available interfaces.

One thing I noticed here is that you cannot specify the interface number for the Loopback; CCP just adds interface sequentially. There was already a Loopback0, so it added the next number- 1. I wonder what would happen if it was Loopback 11 that was there initially- will it start from 0 or continue with 12? You can experiment yourself.

Task #2

The title of this article already gives away what you need to do for this task- configure an access list. Any task that requires you to limit access in some way should give you the hint that an access-list may be required.

Now is a good time to plan your access list: what entries your access list will contain; where it would be applied and so on.

  • As we will be dealing with both source and destination networks, we will need an extended ACL.
  • Keeping in mind that an extended access list should be applied as close to the source of the traffic as possible (1.1.1.1 is on RTR1), and then the ACL should be applied on the Fa0/0 interface of RTR2.
  • The task requires that only 1.1.1.1 (RTR1) should be able to connect to RTR2 on that interface; it means we have to permit 1.1.1.1 to access 22.22.22.22 and deny all other addresses to 22.22.22.22
  • Because of the implicit deny all at the end of every access list, we also have to permit all other traffic.

To configure our access list, we navigate to Router > ACL > ACL Editor and click on the Add button.

The ‘Add a Rule’ dialog box is displayed.

You add access control entries by using the Add button under the Rule Entry section.

The screenshot below shows my first ACE. You can go ahead and add the remaining in a similar manner.

At the end of your ACE additions, you should have something similar to what is shown below.

At this point, we can associate this access list with an interface by clicking in the Associate button.

Once you click OK, the CLI commands preview will be shown (if you still have that option selected). Here are the commands that will be sent to the device:

<code>
ip access-list extended OUTSIDE_IN
 remark filter inbound traffic on Fa0/0
 remark CCP_ACL Category=1
 remark permit 1.1.1.1 to access 22.22.22.22
 permit ip host 1.1.1.1 host 22.22.22.22
 remark deny all other connections to 22.22.22.22
 deny ip any host 22.22.22.22
 remark permit all unmatched traffic
 permit ip any any
 exit
interface FastEthernet0/0
 ip access-group OUTSIDE_IN in
 exit
</code>

I will go ahead and deliver those commands to the router.

Note: When I was writing this article, I mistakenly specified 2.2.2.2 instead of 22.22.22.22. Once I delivered the command, CCP lost connection to the router. I had to go to the CLI to rectify my mistake.

My access list has now been added as shown below:

Task #3

A good habit to develop is testing your configuration. You may probably have taken care of everything but you never know (for example, using 2.2.2.2 instead of 22.22.22.22 like I did). The first thing we notice is that we still have CCP connection, so that’s a good sign but it is not enough. Let’s go over to RTR1 and test our access control. We will use the Utilities box for this.

First I’d try to ping 22.22.22.22 without any advanced options. This should fail because RTR1 isn’t using its Loopback interface (1.1.1.1) for that ping. However, that’s not the only reason as we will see shortly.

Let’s now use the advanced option so we can specify a source interface of 1.1.1.1. This is allowed by our access list so it should succeed.

It still fails. Why is that? This is one of the many advantages of testing your configuration because you get to see if it works or not. Can you figure out why it failed? Find out the solution in the next articleJ.

Summary

This brings us to the end of this article where we have worked through configuration tasks for Lab #1: Access List configuration. We began by adding a new logical (Loopback) interface and then went on to plan and configure our access list. We concluded this article by testing our configuration and found out it does not work as expected. In the next article, we will troubleshoot why this does not work.

It’s been fun going through a lab in this article and I hope you have enjoyed it and found it helpful as much as I enjoyed writing it.

Further reading