Both layer 2 EtherChannel and layer 3 EtherChannel use the same set of commands to create the channel, either through static configuration or using a dynamic protocol (LACP or PAgP). Today’s lab provides a little exercise on all three options (static, PAgP, LACP), in the context of L2 EtherChannels, but it helps you prepare for both L2 and L3 EtherChannel configuration.

Requirements

This lab uses a small LAN with three switches, all acting as layer 2 switches. Several pairs of switches connect with a pair of links that operate as 802.1Q trunks. Your job: make each pair of links operate as a layer 2 EtherChannel.

As a bit of a twist, the initial configuration for this lab pre-configures some details. Your job is to determine the correct configuration that should be added to the initial configuration. By starting out with some configuration, you not only have to think about a nice orderly configuration, but also the impacts of existing configuration on the final EtherChannel configuration.

The specific rules for this lab are:

• Configure the three EtherChannels shown in the figure as follows:
  • Dist1 – Dist2: manually configured.
  • Dist1 – Access 1: Use LACP, with Dist1 initiating the negotiations and Access1 not initiating the negotiations.
  • Dist2 – Access 2: Use PAgP, with Dist2 initiating the negotiations and Access2 not initiating the negotiations.
• All physical links between switches already use 802.1Q trunking per the initial configurations.
• Ensure that the Port Channels act as trunks:
  • Use 802.1Q trunking instead of ISL.
  • Configure all switches to dynamically negotiate trunking, and all switches to initiate that negotiation.

Figure 1: Distribution/Access Switch Topology

Initial Configuration

Examples 1, 2, 3 and 4 show the beginning configuration state of Dist1, Dist2, Access1 and Access2.

Example 1: Dist1 Config

hostname Dist1
!
vlan 2,3,4
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 10 mode on
!
interface GigabitEthernet0/2
 switchport access vlan 2
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 10 mode on
!
interface GigabitEthernet0/3
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 20 mode active
!
interface GigabitEthernet1/0
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 switchport access vlan 2
 channel-group 20 mode active

Example 2: Dist2 Config

hostname Dist2
!
vlan 2,3,4
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 10 mode on
!
interface GigabitEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 switchport access vlan 2
 channel-group 10 mode on
!
interface GigabitEthernet0/3
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 20 mode auto
!
interface GigabitEthernet1/0
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 switchport access vlan 2
 channel-group 20 mode auto

Example 3: Access1 Config

hostname Access1
!
vlan 2,3,4
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 20 mode desirable
!
interface GigabitEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 switchport access vlan 2
 channel-group 20 mode desirable

Example 4: Access2 Config

hostname Access2
!
vlan 2,3,4
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 channel-group 20 mode auto
!
interface GigabitEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode dynamic desirable
 switchport access vlan 2
 channel-group 20 mode auto

Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

To test your solution, if you happen to try it with real gear, you can verify that each of the EtherChannels are up and operational using the appropriate dynamic protocol using the show etherchannel summary command.

Note: As of when this post was published, VIRL did not support LACP to negotiate a trunk. The LACP configuration shown in the answers post is correct, but if you test in VIRL, you will not see a working EtherChannel between Dist1 and Access1.

Note: IOS tends to copy interface configuration over to the automatically-creates portchannel interface, and for good reason. However, that feature means that in your lab, or when using VIRL, you may see slightly different initial configuration based on the timing of when the configuration is added to the switches. So, if you do this lab in VIRL or any other environment, focus more on the final configuration rather than the interim state or the initial configuration state.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly. The host info does as well.

This latest lab asks you to configure layer 2 EtherChannels, but starting with a partial configuration already. Go back and check the lab exercise, create your answer, and check your answer here.

Answers

Figure 1: Distribution/Access Switch Topology

Example 1: Dist1 Config

interface GigabitEthernet0/2
 no switchport access vlan 2
! 
interface port-channel 10
 switchport trunk encapsulation dot1q    ! not required on all models
 switchport mode dynamic desirable       ! Enables trunking
! 
interface port-channel 20
 switchport trunk encapsulation dot1q    ! not required on all models
 switchport mode dynamic desirable       ! Enables trunking

Example 2: Dist2 Config

interface GigabitEthernet0/2
 no switchport access vlan 2
!
interface GigabitEthernet0/3
 channel-group 20 mode desirable         ! Enables PAgP to initiate
!
interface GigabitEthernet1/0
 channel-group 20 mode desirable         ! Enables PAgP to initiate
! 
interface port-channel 10
 switchport trunk encapsulation dot1q    ! not required on all models
 switchport mode dynamic desirable       ! Enables trunking
! 
interface port-channel 20
 switchport trunk encapsulation dot1q    ! not required on all models
 switchport mode dynamic desirable       ! Enables trunking

Example 3: Access1 Config

interface GigabitEthernet0/1
 channel-group 20 mode passive           ! Enables LACP but to react
!
interface GigabitEthernet0/2
 channel-group 20 mode passive           ! Enables LACP but to react
! 
interface port-channel 20
 switchport trunk encapsulation dot1q    ! not required on all models
 switchport mode dynamic desirable       ! Enables trunking

Example 4: Access2 Config

interface port-channel 20
 switchport trunk encapsulation dot1q    ! not required on all models
 switchport mode dynamic desirable       ! Enables trunking

Commentary

The focus of this lab is layer 2 EtherChannel. There are three main ways to configure EtherChannel: Statically configuring it using the on keyword, dynamically configuring it to use LACP, and dynamically configuring it to use PAgP. Both LACP and PAgP have similar goals but are not interoperable with each other.

For this lab you were given a configuration that was initially configured with three different EtherChannel links, none of which was fully formed or working correctly. Your task was to make the necessary alterations to the configuration to meet the requirements listed. It should be noted however that in production environments it is extremely odd to see multiple EtherChannel methods used, for example it is common for an organization (or its architects) to select a specific EtherChannel protocol which is then used across all of its EtherChannel links.

Note that one huge key to interpreting the initial configuration is that the channel-group number interface subcommand causes IOS to create a portchannel interface by that same number. For instance, on switch Dist1, once the first channel-group 10 command was configured, interface portchannel 10 existed, with all default settings.

PortChannel 10 – Dist1 to Dist2

First, focus on Etherchannel 10 between switches Dist1 and Dist2. As initially configured, it has two problems:

1. The two physical links have different access VLAN settings, which prevents both physical links from being active in the EtherChannel at the same time. One physical link uses a default setting of access VLAN 1, while the other is configured with access VLAN 2 (switchport access vlan 2)
2. The portchannel interface is not listed in the configuration, so it uses all default interface subcommands. As a result, it may or may not be correctly configured for trunking at this point, so trunking needs to be configured on the portchannel interface.

On the first point, EtherChannels have a list of configuration settings that must agree before new links can be added to an EtherChannel. One of the settings that must agree is the access VLAN setting – even if the channel will be trunking.  To solve this problem, make the physical links use the same access VLAN setting. In this case, we set both links to use the default setting of access VLAN 1 with the command no switchport access vlan 2 on one physical port (or you could have used switchport access vlan 1).

Once completed, both links in portchannel 10 should be added and active in the channel. Then, to make the portchannel act as a trunk, to match the particulars of the lab instructions, you should add the switchport mode dynamic desirable command. This tells the switch to initiate the dynamic choice to use 802.1Q trunking. (Additionally, on some switches, the switches need to be told to use 802.1Q instead of ISL using the switchport trunk encapsulation dot1q command.)

PortChannel 20 – Dist1 to Access1

Next we will focus on the link between Dist1 and Access1. Per the initial configuration, Dist1 uses LACP because of its channel-group 20 mode active command, and Access1 uses PAgP per the channel-group 20 mode auto command. (The “auto” option happens to be one of the PAgP options, and the “active” option is one of the LACP options.)  Because LACP and PAgP are not compatible with each other, this EtherChannel channel will never form. The requirements state that this link should use LACP with Dist1 being the initiating device. To meet the lab requirements, change the configuration on switch Access1 to use LACP passively; to configure this use the channel-group 20 mode passive command on both links on Access1.

The other requirement for this EtherChannel is to use 802.1Q trunking, so the same configuration required for portchannel 10 between Dist1 and Dist2 is required here as well. To match the lab requirements, on both Dist1 and Access1, add the switchport mode dynamic desirable command, and optionally the switchport trunk encapsulation dot1q command.

PortChannel 20 – Dist2 to Access2

For this last combination, note that we chose the duplicate number of portchannel number 20 on purpose, to duplicate the same portchannel number used between Dist1 and Access1. The portchannel number just has to be unique on a switch. In a real-life design, the designer would likely use a unique number just to make operational tasks more obvious.

For this last EtherChannel, per the initial configuration, both Dist2 and Access2 are configured to use PAgP per the channel-group 20 mode auto command. (The “auto” option one of the PAgP options.) However, the auto parameter causes the switch to wait for the other switch to initiate the channel negotiations, so with both sides using auto, no channel will form. The requirements state that this link should use PAgP with Dist2 being the initiating device, to correct this configuration Dist2 must be modified to use PAgP actively; to configure this use the channel-group 20 mode desirable command on both physical links on Dist2.

The other requirement for this EtherChannel is to use 802.1Q trunking, so the same configuration required for the other two portchannels is required here as well. To match the lab requirements, on both Dist2 and Access2, add the switchport mode dynamic desirable command, and optionally the switchport trunk encapsulation dot1q command.

Configuring PPPoE may seem scary, but it is not too hard from a practical sense. The complex part is understanding each command, and the even more complex part is connecting the configuration to the underlying ideas shown in the related show commands. But the first step is mastering the configuration, and this lab helps with that first step. This lab lets you choose the client-side PPPoE configuration, and gives you another rep on getting good at that config.

Requirements

This lab assumes that you might want to try this lab exercise on your own gear, VIRL, or on a simulator. To that end, the lab can use a crossover cable between the router acting as the PPPoE client router and the ISP router. These two routers would normally sit in different buildings, one owned by the customer and one owned by the ISP, with DSL or some other technology for an Internet access link between the routers. In a lab, to test the PPPoE configuration, the two routers just use an Ethernet link.

For this lab, build a client-side PPPoE configuration to match the following requirements. You do not need to worry about the ISP configuration at all, but it is listed in Example 1 for reference. The specific rules for this lab – all for the client router – are as follows:

• Use the Dialer 20 interface
• Use the Dialer Pool number 10
• Configure the client to dynamically learn it’s IPv4 address on the PPPoE link using PPP protocols (it should learn 198.51.100.101 if you try this in lab, per the ISP router’s initial configuration)
• Configure the MTU to a value that considers the extra PPPoE headers
• Use the ‘Cert’ Authentication hostname and ‘Skills’ Authentication password. (The username/password combination is pre-configured; see Example 2 in this post.)
• Configure a default route using the Dialer 20 interface as the outgoing interface
• Assume all device interfaces shown in the lab are up, working and with correct IP addresses assigned (except for the Client interface connecting to the ISP).

Figure 1: Typical Lab Network for Testing PPPoE Configurations

Initial Configuration

Examples 1 and 2 show the beginning configuration state of ISP and Client devices.

Example 1: ISP Config

hostname ISP
!
username Cert password Skills
!
bba-group pppoe PPPoE_Group
 virtual-template 1
!
interface GigabitEthernet0/1
 pppoe enable group PPPoE_Group
 no shutdown
!
interface Virtual-Template1
 ip address 198.51.100.1 255.255.255.0
 peer default ip address pool PPPoETest
 ppp authentication chap callin
!
ip local pool PPPoETest 198.51.100.101 198.51.100.105

Example 2: Client Config

hostname Client
!
interface GigabitEthernet0/1
 no shutdown
!
interface GigabitEthernet0/2
 ip address 10.10.10.1 255.255.255.0
 no shutdown

Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

To test your solution, if you happen to try it with VIRL or real gear, you can verify the configuration and operation of the dialer interface by issuing the show interfaces dialer 10 command, you can verify the connectivity to the ISP by using the ping 192.0.2.1 command. Also, on the client, try: show interfaces virtual-access 10, show interfaces virtual-access 10 configuration, and show pppoe session.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The VIRL topology matches this lab topology exactly.

Creating a PPPoE configuration requires some practice, so do the lab on your own, and check your answers here. More importantly, find a place to do this lab on gear (or VIRL) or a simulator, and spend the time doing all the verification commands related to PPPoE from Chapter 15 on the ICND2 Cert Guide.  Connecting the details in the verification commands to your configuration is just as big a step.

On to the answers!

Answers

Figure 1: Typical Lab Network for Testing PPPoE Configurations

Example 1: Client Config

interface GigabitEthernet0/1
 pppoe enable
 pppoe-client dial-pool-number 10
!
interface Dialer20
 mtu 1492
 ip address negotiated
 encapsulation ppp
 dialer pool 10
 ppp chap hostname Cert
 ppp chap password Skills
!
ip route 0.0.0.0 0.0.0.0 Dialer20

Commentary

The new ICND2 200-105 book’s Chapter 15 (published 2016) takes a close look at PPPoE configuration. Interestingly, the client side configuration can look scary, with several unfamiliar commands. However, for parameters, all you have to do is select two parameters that just need to be unique on the local router, and then configure those numbers in the correct places. The numbers are the dialer interface number and the dialer pool number.

This particular lab told you what values to use for each parameter, mainly to make it easier to list a single answer configuration here in the lab. Once armed with the dialer interface number of choice (20 in this case) and dialer pool number (10 in this case), you can just follow a template. You also need to know the same username/password combination that the ISP is expecting to hear from the client router as part of the PPP CHAP authentication exchange (Cert/Skills in this case). Figure 2 shows the template:

Figure 2: Figure 15-28 from the ICND2 200-105 Cert Guide

If you use the template in the figure, and compare it to the answer in Example 1, you will find all the commands. The configuration uses interface dialer 20 (per the requirements), as well as dialer pool 10. No one dialer interface number or dialer pool number is better than another. (Note that often an engineer will use the same dialer pool and dialer interface number just to make operations a little simpler.) Other than those numbers, example 1’s sample answer matches the same commands shown here in Figure 2.

This latest lab requires you to configure a point-to-point GRE tunnel, but with no encryption config. Unless this is your first Config Lab, you know the drill. If not: take 5-10 minutes now, read the lab, and type your answer or write it on paper. Then look for the answer post (which usually follows within a day or two if you happen to read this the day it was posted). Check here for all ICND2 Config Labs.

Requirements

Think of the four routers in this lab design as four enterprise routers. All sit in OSPF area 0. However, that one physical link between routers Edge1 and Edge2, now think of that as the entire Internet. (For simplicity in lab, this lab exercise uses that one link as the entire Internet.) So:

• The link between Edge1 and Edge2 are considered to be using public addresses
• All other links use private address (in private network 10.0.0.0)

From a GRE tunnel perspective, you will use the public IP addresses on the link between Edge1 and Edge2 as the tunnel source and destination. Then, for the tunnel interface itself, you will place the interfaces into a subnet in private network 10.0.0.0, you will use OSPF to exchange routes from private network 10.0.0.0, with all subnets in area 0.

The specific rules for this lab are:

• As the tunnel source, use the IP address on the interfaces connecting the Edge routers. (That is, do not refer to the interfaces as the tunnel source.)
• As the tunnel destination, create a local hostname referencing the other Edge router’s Internet-facing IP address (will be interface G0/1 on each router). Then use that hostname as the tunnel destination.
• Assign the tunnel interfaces private IPv4 addresses from network 10.0.0.0 per the figure.
• Configure OSPFv2 in area 0 on the tunnel interface using interface configuration (that is, do not use OSPF network commands).
• Make sure the new OSPF configuration agrees with the existing configuration.
• Assume all device interfaces shown in the lab are up, working and with correct IP addresses assigned.

Figure 1: Two Enterprise Routers at Acme Corp, with One Link Acting as Entire Internet

Initial Configuration

Examples 1, 2, 3 and 4 show the beginning configuration state of Edge1, Edge2, Acme1 and Acme2.

Example 1: Edge1 Config

hostname Edge1
!
interface GigabitEthernet0/1
 ip address 192.0.2.129 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 ip address 10.10.10.1 255.255.255.0
 ip ospf 10 area 0
 no shutdown
!
router ospf 10
 router-id 1.1.1.1

Example 2: Edge2 Config

hostname Edge2
!
interface GigabitEthernet0/1
 ip address 192.0.2.130 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 ip address 10.10.20.1 255.255.255.0
 ip ospf 10 area 0
 no shutdown
!
router ospf 10
 router-id 2.2.2.2

Example 3: Acme1 Config

hostname Acme1
!
interface GigabitEthernet0/1
 ip address 10.10.10.2 255.255.255.0
 ip ospf 10 area 0
 no shutdown
!
interface GigabitEthernet0/2
 ip address 10.100.100.1 255.255.255.0
 ip ospf 10 area 0
 no shutdown
!
router ospf 10
 router-id 3.3.3.3

Example 4: Acme2 Config

hostname Acme2
!
interface GigabitEthernet0/1
 ip address 10.10.20.2 255.255.255.0
 ip ospf 10 area 0
 no shutdown
!
interface GigabitEthernet0/2
 ip address 10.200.200.1 255.255.255.0
 ip ospf 10 area 0
 no shutdown
!
router ospf 10
 router-id 4.4.4.4

Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

To test your solution, if you happen to try it with VIRL or real gear, you can verify the configuration and operation of the tunnel interface by issuing the show interfaces tunnel0 command on routers Edge1 and Edge2. If OSPF is configured correctly it should form a neighborship across the tunnel interface. Also, all four of the routers should learn about all the remote subnets in network 10.0.0.0; for instance, on routers Acme1 and Acme2, a show ip route command should list three subnets learned by OSPF once the lab is completed.

Additionally, look at show ip interface brief, which should show the tunnel interface, it’s IP address, and a state of up/up.

If you do implement this lab, also try a few ping commands. For instance, from router Acme1, the ping 10.200.200.1 source G0/2 command would ping from Acme1’s G0/2 interface address to router Acme2’s G0/2 address (10.200.200.1). That ping would test the routes to subnet 10.100.100.0/24 and back to 10.200.200.0/24.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The VIRL topology matches this lab topology exactly.

You know the drill. Do the lab, come here to check your answer. This one is on configuring a point-to-point GRE tunnel, using a hostname for the tunnel destination, and with OSPF interface thrown in for some quick review.

Answers

Figure 1: Two Enterprise Routers at Acme Corp, with One Link Acting as Entire Internet

Example 1: Edge1 Config

ip host edge2 192.0.2.130
!
interface Tunnel0
 ip address 172.16.1.1 255.255.255.252
 tunnel source 192.0.2.129
 tunnel destination edge2
 ip ospf 10 area 0

Example 2: Edge2 Config

ip host edge1 192.0.2.129
!
interface Tunnel0
 ip address 172.16.1.2 255.255.255.252
 tunnel source 192.0.2.130
 tunnel destination edge1
 ip ospf 10 area 0

Commentary

Many enterprises use GRE tunnels, either directly as configured in this lab, or multipoint GRE tunnels as implemented with DMVPN. Getting a good handle on the basic GRE encapsulation and configuration is a good beginning step for a CCNA to learn before moving into the details of configuring IPsec encryption to be used over that tunnel.

For this lab you are tasked with configuring a manual point-to-point GRE tunnel between Edge routers, and then configuring OSPF over this newly configured tunnel. This lab differs from the earlier labs because it utilizes tunnel source IP addresses (instead of interfaces), and tunnel destination hostnames (instead of addresses).

First, think about the big picture. The routers will use these IP addresses as the tunnel source and destination, per the requirements in the lab plus the network diagram:

Edge1: Source is 192.0.2.129, destination is 192.0.2.130

Edge2: Source is 192.0.2.130, destination is 192.0.2.129

The lab instructions ask you to configure the source IP address directly (that is, do not reference the interface in the tunnel source command). So, looking at Examples 1 and 2, the two tunnel source commands simply refer to the IP addresses just mentioned: 192.0.2.129 (Edge1) and 192.0.2.130 (Edge2).

Next, the lab asked you to use a locally-defined hostname to refer to the tunnel destination. The Examples use obvious names, for instance, using the ip host edge2 192.0.2.130 command on Edge1 to define a hostname for Edge2’s address. Similarly, Edge2’s configuration uses the ip host edge1 192.0.2.129 command. Once configured, the tunnel destination commands can just reference those hostnames, with the tunnel destination edge2 command on router Edge1 and the tunnel destination edge1 command on router Edge2.

At this point, the GRE tunnel itself has been configured, and the next step is to enable IPv4 and then OSPF. Per the figure, Edge1 uses address 10.1.1.1, with Edge2 using 10.1.1.2, both with mask /30. Then both routers’ tunnel interfaces need the ip ospf 10 area 0 command, which enables OSPF for OSPF process 10, and places the tunnel interface into area 0. Note that OSPF process 10 had already been configured on both Edge1 and Edge2 per the initial configuration; that initial configuration is how you would know to use a “10” in the command as the OSPF process ID.

#CCNA candidates can struggle with SNMP configuration for a couple of reasons. First, in real life, you configure SNMP on each device and then ignore the configuration. Because of that, when you do have to configure it, most of us copy the config from another device, or from a template, so you might even configure SNMP on a new device without even remembering what the commands do.

This lab gives you a chance to practice SNMP and exercise your memory of the commands. It also adds a twist: restricting SNMP rights to only a small range of IPv4 addresses.

Requirements

For this lab, configure SNMP on both routers in the figure. Additionally, configure the routers so that the router ignores SNMP packets from hosts except those sent from hosts in subnet 172.16.1.0/24.

Note that the lab begins with all the interfaces shown in Figure 1 connected and IP addresses configured, with EIGRP used to learn routes. Specifically, use the following requirements for both routers:

• Use SNMP version 2c
• Use an SNMP read only password of ‘readonly’
• Use an SNMP write password of ‘readwrite’
• Limit all community access to the 172.16.1.0/24 network using ACL 1
• Use an SNMP Location of ‘Cincinnati’
• Use an SNMP Contact of ‘Chris’

Figure 1: Two Routers with IP Addresses

Initial Configuration

Examples 1 and 2 show the beginning configuration state of R1 and R2.

Example 1: R1 Config

hostname R1
!
interface GigabitEthernet0/1
 ip address 10.15.20.1 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 ip address 172.17.1.1 255.255.255.0
 no shutdown
!
router eigrp 1
 network 10.0.0.0
 network 172.17.0.0

Example 2: R2 Config

hostname R2
!
interface GigabitEthernet0/1
 ip address 10.15.20.2 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 ip address 172.16.1.2 255.255.255.0
 no shutdown
!
router eigrp 1
 network 10.0.0.0
 network 172.16.0.0

Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab using them.

If you do try this on real gear, the trick is to test the ability to retrieve SNMP data using the SNMP GET protocol message. To do that, try searching for tools online like snmpget and snmpwalk. These tools let you send SNMP GET messages without a full-fledged NMS installed. In particular, if you text in a lab with a Linux host or VM available, snmpwalk -v 2c -c string ip-address. Begin with a ping of the router IP address, to make sure connectivity exists. If that works, and you configure SNMP correctly on the router, then your SNMP test will hopefully work.

To test whether the ACL restricts the traffic or not, you can either change the address of the host from which you test, or change your ACL. For instance, find the IP address used on the host from which you are testing. Then change your ACL on R1 to specifically deny traffic from that host’s IP address. Then re-try your SNMP tests, and the requests should now fail.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

Network Device Info

The VIRL file uses the exact same ports and topology as the original lab exercise.

Host Device Info

This table lists host information pre-configured in VIRL, information that might not be required by the lab but may be useful to you.

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping -c 4 10.1.1.1

Trace example: tracepath 10.1.1.1

To connect to another node within the topology: telnet 10.1.1.1

This latest lab lets you practice configuring SNMP. At the same time, it lets you configure restrictions so that only some devices are allowed to even use SNMP with the routers in the lab. Check out the lab requirements first, write down your own answer, and then come back here to check your answer.

Answers

Figure 1: Two Routers with IP Addresses

Example 3: R1 Config

access-list 1 permit 172.16.1.0 0.0.0.255
access-list 1 remark with only one line, this ACL denies all else
!
snmp-server community readonly ro 1
snmp-server community readwrite rw 1
snmp-server location Cincinnati
snmp-server contact Chris

Example 4: R2 Config

access-list 1 permit 172.16.1.0 0.0.0.255
!
snmp-server community readonly ro 1
snmp-server community readwrite rw 1
snmp-server location Cincinnati
snmp-server contact Chris

Commentary

With SNMP version 2c (SNMPv2c), the only security mechanism was to use a simple text password called a community string. Any NMS with knowledge of the read/write community could then change anything accessible to the SNMP agent on the device, which on Cisco routers and switches includes the configuration. Further securing SNMPv2c by restricting the IP addresses allowed to connect to the router makes sense. (Using SNMPv3 makes even more sense.)

In this case, the snmp-server community commands end with a “1”, which refers to access-list 1. ACL 1 permits all traffic from subnet 172.16.1.0/24, that is, from the subnet in which the NMS resides. Without the “1” on the end, these first two commands would have enabled SNMP, with no ACL to restrict acces, so that anyone who knew the very poorly chosen community values of “readonly” and “readwrite” would have access to the routers using SNMP.

The two remaining commands on each router simply set the location and contact, which SNMP will use as values for two different SNMP variables.

Are you comfortable matching packets with extended ACLs? How about with TCP and UDP ports in those ACLs? Here’s a 10-minute lab exercise to practice; all you need is the time and a piece of paper or a place to type!

Requirements

Configure an extended access list to control that traffic as detailed in the following rules:

• Create an extended named ACL, with name “ThisACL”, which performs the following functions:
  • Permit all traffic coming from the telnet, SSH and SNMP server at address 10.0.3.100, going to the the 20.0.2.0/24 subnet displayed in the figure
  • Block all other traffic coming from telnet, SSH, and SNMP servers in the 10.0.3.0/24 subnet, going to the 20.0.2.0/24 subnet
  • Permit all other traffic
• Apply the ACL on the appropriate device per the figure
• Assume all router interfaces shown in the lab are up, working and have correct IP addresses assigned
• Assume routing between all devices is configured and operational

Figure 1: Two Router ROAS Topology

Initial Configuration

Examples 1, 2, 3 and 4 shows the beginning configuration state of R1, R2, SW1 and SW2.

Example 1: R1 Config

hostname R1
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 no shutdown
!
interface GigabitEthernet0/2.1
 encapsulation dot1q 10
 ip address 10.0.1.1 255.255.255.0
!
interface GigabitEthernet0/2.2
 encapsulation dot1q 20
 ip address 10.0.2.1 255.255.255.0
!
interface GigabitEthernet0/2.3
 encapsulation dot1q 30
 ip address 10.0.3.1 255.255.255.0
!
router eigrp 10
 network 0.0.0.0

Example 2: R2 Config

hostname R2
!
interface GigabitEthernet0/1
 ip address 192.168.1.2 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/2
 no shutdown
!
interface GigabitEthernet0/2.1
 encapsulation dot1q 10
 ip address 20.0.1.1 255.255.255.0
!
interface GigabitEthernet0/2.2
 encapsulation dot1q 20
 ip address 20.0.2.1 255.255.255.0
!
interface GigabitEthernet0/2.3
 encapsulation dot1q 30
 ip address 20.0.3.1 255.255.255.0
!
router eigrp 10
 network 0.0.0.0

Example 3: SW1 Config

hostname SW1
!
vlan 10,20,30
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!
interface GigabitEthernet0/2
 switchport access vlan 10
!
interface GigabitEthernet0/3
 switchport access vlan 20
!
interface GigabitEthernet1/0
 switchport access vlan 30

Example 4: SW2 Config

hostname SW2
!
vlan 10,20,30
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!
interface GigabitEthernet0/2
 switchport access vlan 10
!
interface GigabitEthernet0/3
 switchport access vlan 20
!
interface GigabitEthernet1/0
 switchport access vlan 30

Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

To test your solution, if you happen to try it with VIRL or real gear, you can check by verifying it with the show ip access-lists and show ip interfaces commands. If possible you could also configure hosts to the topology to ensure the access-list is working as expected.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly. The host info does as well.

Host device info:

This table lists host information pre-configured in VIRL, information that might not be required by the lab but may be useful to you.

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping -c 4 10.1.1.1

Trace example: tracepath 10.1.1.1

To connect to another node within the topology: telnet 10.1.1.1

No muss, and just a little fuss with thinking about SNMP, today’s lab is mostly about how to match packets with an extended numbered ACL. Do the lab for yourself, and check here when you’re done.

Answers

Figure 1: Two Router ROAS Topology

Example 5: R1 Config

interface GigabitEthernet0/2.3
 ip access-group ThisACL in
!
ip access-list extended ThisACL
 permit tcp host 10.0.3.100 eq telnet 20.0.2.0 0.0.0.255
 permit tcp host 10.0.3.100 eq 22 20.0.2.0 0.0.0.255
 permit udp host 10.0.3.100 eq snmp 20.0.2.0 0.0.0.255
 deny   tcp 10.0.3.0 0.0.0.255 eq telnet 20.0.2.0 0.0.0.255
 deny   tcp 10.0.3.0 0.0.0.255 eq 22 20.0.2.0 0.0.0.255
 deny   udp 10.0.3.0 0.0.0.255 eq snmp 20.0.2.0 0.0.0.255
 permit ip any any

Commentary

The primary use of access-lists is to control which traffic is allowed to come in and go out of the interfaces of a device. On Cisco devices there are a number of different ways to configure them; for IPv4 the two main methods are via the use of standard or extended ACL’s. Standard ACL’s are simpler and only allow matching based on the source IP host or network of the traffic. Extended ACL’s are more complex and allow matching on both source and destination host or network as well as matching based on the protocol being used. It is important to note however that ACL’s are not limited to the blocking or permitting of specific traffic, they are also used in a number of different features from Network Address Translation (NAT) to route-maps.

With this lab you were tasked with configuring an extended named ACL that would be used to block specific traffic. In particular, the two requirements ask that you match packets coming from servers, which means that the source TCP or UDP port in those packets will be used to match the well-known ports used by those servers. The first requirement asked you to match packets from a specific server, while the second requirement asked that you match packets coming from an entire subnet.

For that first requirement, you needed to match the specific server address (10.0.3.100) with the host 10.0.3.100 parameters, and the destination subnet with the 20.0.2.0 0.0.0.255 parameters. Beyond that, for three consecutive commands, the ACL needed a separate statement to match each service noted in the requirements, for the well-known port used by Telnet (21), SSH (22), and SNMP (161), and for the correct transport protocols (see example 1).

For the second requirements, the logic works the same, except that the source field in each case matches the source subnet with the 10.0.3.0 0.0.0.255 parameters.

The last step is to apply the ACL to the appropriate interface. It is considered best practice to apply standard ACLs to the interface that is closest to the destination and extended ACLs to the interface that is closest to the source. In this case since you are configuring an extended ACL you are looking for the interface that is closest to the source. Since R1 is configured with a Router-on-a-Stick (ROAS) configuration the closest interface would be a sub-interface not a physical interface. The source network is 10.0.3.0/24 which is located off R1’s G0/2.3 sub-interface, so the answer applies the ACL inbound on this interface using the ip access-group ThisACL in command.

Finally, note that this lab glossed over one SNMP issue. As worded, the lab exercise requirements mentioned Telnet, SSH and SNMP server. As it turns out, SNMP does not often use client and server terms. However, the device using well-known UDP port 161, which is matched by an IOS ACL with the snmp keyword, is the SNMP agent running on the networking device. So, in the literal sense, the ACL listed here is correct. However, many people incorrectly think of the Network Management Station as the the server; if that was your intent, then note that the NMS would not send packets with source UDP port 161, but rather with destination UDP port 161 when communicating to SNMP agents throughout the network.

SNMPv3 configuration may be the most challenging new configuration topic added to the new CCNA R&S exams introduced in May 2016 (that is, CCNA R&S 200-125). The configuration commands have many options, and it is possible to configure an incorrect combination of options that just does not work. So you need to take extra care to combine the right options. This lab sets up a straightforward set of SNMPv3 requirements so that you can then focus on practicing getting the command options right.

Requirements

This lab uses a small network with two routers. Your job is to create a configuration that would work on both routers to enable SNMPv3, per the following requirements:

• Use username Youdda
• Use group name Certskills
• Use text string mysecretpassword for any passwords or keys
• Support both reading (Get) and writing (Set) to the MIB
• Use the default MIB view (V1Default) if any MIB views need to be configured
• Support traps, but not informs, sent to the SNMP manager at address 172.16.2.9
• Use SNMPv3 authentication with SHA, but do not use privacy
• Do not filter messages based on an ACL
• As for the topology:
  • Assume all interfaces shown in the figure are up and working, that is, there is connectivity between each router and the SNMP server.

Figure 1: Topology Used for SNMPv3 Labs

Initial Configuration

Examples 1 and 2 show the initial configurations on routers R1 and R2, respectively.

Example 1: Router R1 Initial Configuration

hostname R1
!
interface GigabitEthernet0/1
 no shutdown
 ip address 172.20.1.1 255.255.255.0
!
interface gigabitethernet0/2
 no shutdown
 ip address 172.20.12.1 255.255.255.0
!
router ospf 1
 network 172.20.1.1 0.0.0.0 area 0
 network 172.20.12.1 0.0.0.0 area 0

Example 2: Router R2 Initial Configuration

hostname R2
!
interface GigabitEthernet0/1
 no shutdown
 ip address 172.20.2.2 255.255.255.0
!
interface gigabitethernet0/2
 no shutdown
 ip address 172.20.12.2 255.255.255.0
!
router ospf 1
 network 172.20.2.2 0.0.0.0 area 0
 network 172.20.12.2 0.0.0.0 area 0

Answer on Paper, or Maybe Test in Lab

As always, you should at least answer on paper or by typing in a text editor.

If you do implement this config lab on real gear or some other tool, it is difficult to verify without having an SNMP manager with which to test. The challenge is that the router will accept combinations of commands that fail when trying to communicate with the SNMP manager. For those of you who want to dig a little deeper, and you have at least one router or switch in your home lab, then consider downloading any free SNMP manager. Then make sure your manager can successfully do an SNMP Get to pull information from your router or switch after adding the kind of configuration you build in this lab.

Note that for the purposes of learning SNMPv3, I found that the ManageEngine MIB Browser was a good tool. It gives you enough direct control so that you can see what is happening. However, it may be a more difficult tool to use for someone starting out, in that it requires you to navigate the MIB structure.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly. The host info does as well.

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping -c 4 10.1.1.1

Trace example: tracepath 10.1.1.1

To connect to another node within the topology: telnet 10.1.1.1

This lab gave you six or seven separate facts about how to configure SNMPv3. Focus on remembering all those little moving parts of the various SNMPv3 configuration commands. Most people will not memorize those, but you should think and practice these combinations so that you can see the configuration not as a long confusing set of words, but as separate ideas, and to understand each idea. As always, do the lab, then check your answers here.

Answers

Figure 1: Topology Used for SNMPv3 Labs

Example 3: Router R1 and R2 – Identical Config

snmp-server group Certskills v3 auth write v1default
snmp-server user Youdda Certskills v3 auth sha mysecretpassword
!
snmp-server enable traps
snmp-server host 10.1.3.3 version 3 auth Youdda

Commentary

The four configuration commands show the correct syntax that then matches the logic shown in the requirements. Working through the sample answer’s four commands in the same order as listed in Example 3:

Command 1: snmp-server group

The first command creates an SNMP group, which is a configuration concept which gathers some SNMPv3 parameters for easy reference by the snmp-user user command. It is simply the way Cisco’s team built the SNMPv3 configuration.

The command lists these key parameters:

group Certskills: defines the name of the group with a name that I made up, and that you used based on the requirements for the lab.

v3: keyword that defines the version.

auth: defines that this group performs authentication, but not privacy

write v1default: two combined parameters that enable the use of Sets (for writing to the router’s MIB), with MIB view v1default.

Also, this command can be the starting point for some common mistakes. In this case, note that the use of the auth keyword on this command means that auth must be used on any snmp-server user commands that refer to this group.

Command 2: snmp-server host

The second command completes the work to enable support for Get and Set commands.  This command defines the user (Youdda per the instructions) and links it to the first command. Specifically:

Certskills: refers to the name listed in the snmp-server group Certskills command.

v3: keyword that defines the version.

auth sha mysecretpassword: defines that the user should use authentication, with SHA as the protocol, with a password of mysecretpassword.

Command 3: snmp-server enable traps

The third command is simple: it enables the router to send Trap (and Inform) messages assuming the rest of the related configuration in command 4 is completed.

Command 4: snmp-server user

The last command completes the Trap configuration. Traps (and Informs) require that the router know to what IP address to send the Trap or Inform message, that is, the address of the SNMP manager. This command defines the address, and whether to send Traps or Informs, as follows:

host 172.20.2.9: Identifies the IP address of the SNMP manager.

version 3: keywords that define the version.

auth: defines that the user should use authentication (not privacy).

Youdda: defines the username (per the snmp-server user command) used for SNMPv3 authentication.

The first step to see useful SPAN output in a network analyzer (like Wireshark) begins with a packet capture. In a network with Cisco switches, that means configuring a Switched Port Analyzer (SPAN) session to direct the to-be-captured messages to the analyzer. This next lab gives you some basic requirements, with a common over-arching requirement: collect all the messages that matter, while avoiding gathering too many messages.

Requirements

Configure local SPAN on switch SW1 in the figure. Note that with SPAN it is difficult to capture exactly the subset of messages you want to capture. So, you have two goals: a primary goal that defines all the messages that you must capture, and secondary goal of capturing as few extra messages beyond those requested as part of the primary goal.

The requirements for this lab are as follows:

• The primary goal: capture all frames flowing between PC1 and PC2
• The secondary goal: capture as few extra frames as possible, which then requires less filtering on the network analyzer to then show all the messages sent between PC1 and PC2.
• Configure all SPAN parameters, even default parameters, in an effort to practice remembering all command parameters
• You may capture per interface, or per VLAN, and for any direction needed to meet the goals
• As for the topology:
  • All devices sit in VLAN 2
  • All devices use IP addresses in subnet 172.16.2.0/24, with the last octet of each respective address shown in the figure near the device.
  • Trunking is not used between the switch and the router
  • The rest of the enterprise network (not shown) exists to the right of the router
  • The server on the left is the network analyzer

Figure 1: Single Switch Topology for Local SPAN Configuration

Initial Configuration

Example 1 shows the initial configuration on switch SW1.

Example 1: Switch SW1 Configuration

hostname SW1
!
vlan 2
!
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 2
!
interface GigabitEthernet0/2
 switchport mode access
 switchport access vlan 2
!
interface GigabitEthernet0/3
 switchport mode access
 switchport access vlan 2
!
interface GigabitEthernet1/0
 switchport mode access
 switchport access vlan 2
!
interface GigabitEthernet1/1
 switchport mode access
 switchport access vlan 2
!
interface GigabitEthernet1/2
 switchport mode access
 switchport access vlan 2

Answer on Paper, or Maybe Test in Lab

To answer on paper, the process is of course simple: write your answer, and check it against the answer post that follows this post.

To test in lab, if you build this lab exercise in hardware, you will need to download and install a network analyzer on the computer that sits where the server sits in the figure. The process of how to do that is beyond the scope of this lab. However, if you start at www.wireshark.org and follow the instructions.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly. The host info does as well.

Host device info:

This table lists host information pre-configured in VIRL, information that might not be required by the lab but may be useful to you.

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping6 -c4 2001:0:0:10::100

Trace example: tracepath6 2001:0:0:10::1

A Word about Packet Captures for this Lab

VIRL does support the ability to capture packets, which allows you to then feed the packets into Wireshark running on your computer. Basically you tell VIRL on what interface to capture, and then direct VIRL where to send the packets. However, the specifics require several steps. So, I’ve left the rest of the details out of the blog post here, other than to mention that you can further research this feature on your own if you happen to use VIRL.

Configuring local SPAN does not take a lot of commands. The bigger danger is capturing too much, which risks losing some of the messages and also causing you more work to see the content that you want to see. As usual, for these config labs, start by doing the lab for yourself, then check back to this answer post for my suggested answer and some explanation.

Answers

Figure 1: Single Switch Topology for Local SPAN Configuration

Example 2: SW1 Config

monitor session 1 source interface GigabitEthernet0/1 both
monitor session 1 destination interface GigabitEthernet1/1

Commentary

This lab gives you a primary and secondary goal for what you should capture. There are several ways to capture messages with SPAN to meet the primary goal, and of those, more than one answer would meet both the primary and secondary goal. This commentary works through some of those choices, and then looks specifically at the answer listed here.

First, SPAN can monitor for frames being received on the switch port (that is, coming into the switch), frames being transmitted out the switch port, and in both directions. The source can be one (or more) individual ports, or it can reference a VLAN. If referencing a VLAN, the SPAN session performs the capture action for all ports in the VLAN (access ports and trunk ports that support that VLAN).

With the primary goal of capturing messages sent between PC1 and PC2, you have several options to meet that requirement:

1. Capture all frames both sent and received on port G0/1 (PC1’s port) (as shown in the solution)
2. Capture all frames both sent and received on port G0/2 (PC2’s port)
3. Capture all frames sent in the VLAN (which includes all frames sent out ports G0/1 and G0/2)
4. Capture all frames received in the VLAN (which includes all frame received in ports G0/1 and G0/2)
5. Capture all frames received on both port G0/1 (which includes frames sent by PC2 to PC1) and frames received on port G0/2 (which includes frames sent by PC1 to PC2)
6. As with the previous, but capture in the transmit direction

All of these options collect more frames than the frames requested in the primary requirement for this lab. The secondary goal then asks us to capture as few additional frames as possible. For instance, the options that capture all traffic in the VLAN capture frames sent and/or received on the ports connected to PC3 and PC4, and to router R1, none of which is necessary. So the solutions that use individual ports will be a better solution.

The suggested answer captures messages that fit into these general descriptions:

Capture frames entering SW1’s G0/1 interface, which are all frames sent by PC1 (including frames sent by PC1 to PC2)

Capture frames exiting SW1’s G0/1 interface, which are all frames received by PC1 (including frames sent by PC2 to PC1)

As you can see from those descriptions, the configuration meets the primary requirement. It avoids capturing known unicast frames sent between PC2, PC3, PC4, and router R1, which reduces the amount of frames captured. But it still captures some extra frames, for example, it would capture frames sent by PC1 to any other device.

IPv6 ACLs – new to #CCNA with the 2016 exam revisions – include both standard and extended ACLs. However, IPv6 standard and extended ACLs have only subtle configuration differences. This lab helps you notice those differences with a lab that happens to use requirements that can be implemented with a standard IPv6 ACL, namely, the matching of the source and destination IPv6 addresses alone.

Requirements

This lab gives you a set of relatively straightforward IPv6 standard ACL requirements for matching the source and destination IPv6 address ranges. At the same time, the lab gives you enough space to think beyond the configuration. You must work through an existing configuration, get your bearings, choose where to put the ACL, and in which direction to place the ACL.

The specific rules for this lab are:

• Create a standard IPv6 named ACL named “StdACL01” which performs the following functions:
  • Block all traffic from the 2001:0:0:10::/64 subnet, destined to both subnet 2001:0:0:30::/64 and subnet 2001:0:0:40::/64.
  • Block all traffic from the 2001:0:0:20::100 host, destined to both subnet 2001:0:0:30::/64 and 2001:0:0:40::/64.
  • Permit all other traffic
• You may use one ACL only, enabled on one of the routers only
• You choose the device on which to enable the ACL, the interface(s), and the direction(s)
• As seen in the initial configurations:
  • Assume all router interfaces shown in the lab are up, working and have correct IPv6 addresses assigned
  • Assume routing between all devices is configured and operational, that is, before adding the IPv6 ACLs, all existing IPv6 addresses are pingable
  • Assume that at least one device exists on each VLAN with an IP address ending in :100 with correct gateways configured.

Figure 1: Two Router ROAS Topology for IPv6 Standard ACLs

Initial Configuration

Examples 1, 2, 3 and 4 show the beginning configuration state of R1, R2, SW1 and SW2.

Example 1: R1 Config

hostname R1
!
ipv6 unicast-routing
!
ipv6 router eigrp 1
 eigrp router-id 1.1.1.1
!
interface GigabitEthernet0/1
 ipv6 address 2001:0:0:1::1/64
 ipv6 eigrp 1
 no shutdown
!
interface GigabitEthernet0/2
 no shutdown
!
interface GigabitEthernet0/2.1
 encapsulation dot1q 10
 ipv6 address 2001:0:0:10::1/64
 ipv6 eigrp 1
!
interface GigabitEthernet0/2.2
 encapsulation dot1q 20
 ipv6 address 2001:0:0:20::1/64
 ipv6 eigrp 1

Example 2: R2 Config

hostname R2
!
ipv6 unicast-routing
!
ipv6 router eigrp 1
 eigrp router-id 2.2.2.2
!
interface GigabitEthernet0/1
 ipv6 address 2001:0:0:1::2/64
 ipv6 eigrp 1
 no shutdown
!
interface GigabitEthernet0/2
 no shutdown
!
interface GigabitEthernet0/2.1
 encapsulation dot1q 30
 ipv6 address 2001:0:0:30::2/64
 ipv6 eigrp 1
!
interface GigabitEthernet0/2.2
 encapsulation dot1q 40
 ipv6 address 2001:0:0:40::2/64
 ipv6 eigrp 1

Example 3: SW1 Config

hostname SW1
!
vlan 10,20
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!
interface GigabitEthernet0/2
 switchport access vlan 10
!
interface GigabitEthernet0/3
 switchport access vlan 20

Example 4: SW2 Config

hostname SW2
!
vlan 30,40
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!
interface GigabitEthernet0/2
 switchport access vlan 30
!
interface GigabitEthernet0/3
 switchport access vlan 40

Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

To test your solution if you happen to try it with VIRL or real gear, you can check by verifying it with the show ipv6 access-lists and show ipv6 interfaces commands. If possible you could also configure additional hosts to the topology to ensure the access-list is working as expected.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly. The host info does as well.

Host device info:

This table lists host information pre-configured in VIRL, information that might not be required by the lab but may be useful to you.

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping6 -c4 2001:0:0:10::100

Trace example: tracepath6 2001:0:0:10::1

The previous lab exercise requires you to configure a standard IPv6 ACL. The address range matching should be pretty straightforward. You also need to choose where to put the ACL, and for which direction of flow for the packets. As usual, check the requirements from the previous lab exercise and make your own answer first – it’s an exercise for you. Enjoy!

Answers

Figure 1: Two Router ROAS Topology for IPv6 Standard ACLs

Example 5: R2 Config

interface GigabitEthernet0/2.1
 ipv6 access-group StdACL01 out
!
interface GigabitEthernet0/2.2
 ip access-group StdACL01 out
!
ipv6 access-list StdACL01
 deny ipv6 2001:0:0:10::/64 2001:0:0:30::/64
 deny ipv6 2001:0:0:10::/64 2001:0:0:40::/64
 deny ipv6 host 2001:0:0:20::100 2001:0:0:30::/64
 deny ipv6 host 2001:0:0:20::100 2001:0:0:40::/64
 permit ipv6 any any

Commentary

With this lab you were tasked with configuring a standard IPv6 ACL. The requirement to create a standard IPv6 ACL versus an extended IPv6 ACL is actually pretty subtle, because the difference in commands is not as obvious as it is with IPv4 standard and extended ACLs. In short, IPv6 ACLs that match only the source and destination IPv6 address fields are standard IPv6 ACLs. If your ACL matched only on the source and destination IPv6 addresses, then you met the first requirement.

Next, before choosing whether to place a particular address range as the source or destination address, you must choose both the location and direction for the ACL. The lab requirement wording listed source addresses from the IPv6 prefixes at the top of the figure, with destination prefixes at the bottom of the figure. You could have placed the ACL on either R1 or R2 in this case, and for either direction, and still met the lab’s requirements. For the purposes of this lab, the answer shows the ACL on router R2, for the direction from the upper subnets to the lower subnets. Also, the solution enables the ACL in the outbound direction on the ROAS subinterfaces (the subinterfaces of R2’s G0/2 physical interface.)

The matching is relatively straightforward. The first requirement lists a source subnet of 2001:0:0:10::/64, and with two destination subnets. To match for this requirement, you need one statement, one for each destination subnet. The second requirement is similar, with a source host address of 2001:0:0:20::100, and with the same two destination subnets. In this case, the source address field can be matched with the host keyword before the host IPv6 address.

The ACL closes with a permit ipv6 any any command, which meets the requirement to permit all other traffic.

This lab also might have made you wonder if the ACL could have been applied to the G0/2 physical interface in this case, filtering all IPv6 traffic exiting the interface, and the answer is no. An ACL applied under physical interface G0/2 – not one of its subinterfaces – would be considered for packets routed out G0/2, but not for packets routed out its subinterfaces. So, as shown in the answer, the ipv6 access-group StdACL01 out command is used as a subcommand on both subinterfaces.

Multilink PPP (MLPPP) makes multiple parallel links act like one link from a layer 3 perspective. Then, when a router’s layer 3 routing decides to forward a layer 3 packet out the layer 3 MLPPP multilink interface, the router has to choose which of the several MLPPP-controlled links to use. To do that, the router’s MLPPP layer 2 logic takes over to load balance the message over the multiple links. This next lab gives you a chance to practice MLPPP configuration, starting from scratch, by configuring two serial links to be in one multilink PPP group. No muss, no fuss, just practice making MLPPP work on a pair of serial links.

Requirements

Configure MLPPP on both router R1 and R2 in the figure, so that the routers have a single subnet (172.16.12.0/24) used between the two routers. You should think of this lab as a complete configuration for MLPPP, but also think about any changes needed based on the initial configuration to this lab. Follow these requirements:

• Configure the two serial links to use MLPPP:
  • Use MLPPP interface 1
  • Use subnet 172.16.12.0/24
  • Give R1 an IPv4 address that ends with .1, and R2 an address that ends with .2
  • Do not use any PPP authentication
• As for the transition from the existing configuration, examine the initial configurations shown in this lab exercise, and decide whether or not any existing configuration needs to be updated as a result:
  • Check the OSPF configuration, and make changes as needed, so that both routers still become OSPF neighbors and still exchange routes for their LAN subnets
  • Check the IP addressing configuration to remove any IP address overlaps or remove any unnecessary IP addresses.
• As for the topology:
  • Assume all interfaces shown in the figure are up and working

Figure 1: MLPPP Topology

Initial Configuration

Examples 1 and 2 show the initial configurations on routers R1 and R2, respectively.

Example 1: Router R1 Initial Configuration

hostname R1
!
interface GigabitEthernet0/1
 no shutdown
 ip address 172.16.1.1 255.255.255.0
!
interface serial 0/0/0
 no shutdown
 clock rate 1536000
!
interface serial 0/0/0
 no shutdown
 clock rate 1536000
!
router ospf 1
 network 172.16.0.0 0.0.255.255 area 0

Example 2: Router R2 Initial Configuration

hostname R2
!
interface GigabitEthernet0/1
 no shutdown
 ip address 172.16.2.2 255.255.255.0
!
interface serial 0/0/0
 no shutdown
 clock rate 1536000
!
interface serial 0/0/0
 no shutdown
 clock rate 1536000
!
router ospf 1
 network 172.16.0.0 0.0.255.255 area 0

Answer on Paper, or Maybe Test in Lab

To answer on paper, or in a text editor, just write your answers. The next post will list my suggested solution. And with this particular lab, as worded, there should be only a single correct answer.

To test in lab, you cannot use VIRL, because this lab uses serial interfaces. However, you can use Packet Tracer or real hardware. Feel free to do the lab in either environment. You can use any serial interface numbers that you want to use.

If you do implement this lab, try these show commands to get some insights into your solution:

show ppp multilink

show interfaces multilink 2

show ip interface brief

show ip ospf interface

Configuring multilink PPP (MLPPP) uses a large number of commands for a single feature. However, many of the commands are repetitive on several interfaces. The trick is to figure out which commands are repeated on both the physical and multilink interface, and which ones are configured only on one or the other type of interface. Do the lab on your own first, and then check here for my answer and explanation.

Answers

Figure 1: MLPPP Topology

Example 3: Router R1 Config

interface serial 0/0/0
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
!
interface serial 0/0/1
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
!
interface multilink 1
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 ip address 172.16.12.1 255.255.255.0

Example 4: Router R2 Config

interface serial 0/0/0
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
!
interface serial 0/0/1
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
!
interface multilink 1
 encapsulation ppp
 ppp multilink
 ppp multilink group 1
 ip address 172.16.12.2 255.255.255.0

Commentary

You can think of MLPPP configuration as having two major ideas, even though the configuration does not make these two ideas obvious. The first is that IOS requires a virtual interface, called a multilink interface, to act as the layer 3 interface for MLPPP. Each MLPPP multilink interface is assigned an integer interface number. The second big idea is that each physical serial link needs to be associated with that MLPPP group through the multilink interface concept, by virtue of a reference to the multilink interface number.

Keeping those ideas in mind, the configuration of the first big idea focuses on these two commands found on router R1 (along with the similar commands on R2):

interface multilink 1

ip address 172.16.12.1 255.255.255.0

These commands create the multilink interface on router R1, and enable IPv4 on the link, respectively. Router R2 has similar commands, setting address 172.16.12.2. As a result, the concept of a single MLPPP link between the two routers is configured.

The second big idea, which correlates the physical interfaces with the multilink interface on each router. To do so, each router uses the same interface subcommand on the physical serial interfaces and the multilink interface itself: the ppp multilink group 1 command.

Finally, the configuration must also enable PPP as well as the MLPPP feature with two separate commands, again on both the physical and multilink interfaces, as done with these two commands.

encapsulation ppp

ppp multilink

To summarize the key points, an MLPPP configuration includes:

• The same three commands on the physical and multilink interfaces (encapsulation ppp, ppp multilink, ppp multilink group x)
• The no ip address command configured (which is the default) on serial interfaces
• The ip address command configured on the multilink interfaces

Finally, note that the lab asked you to consider possible changes to the initial configuration. In this lab, no such changes are needed. Here’s why:

• The OSPF configuration already matches all interfaces whose addresses begin with 172.16, so the new multilink interface is already matched and added to OSPF area 0.
• The existing IP addresses do not overlap with the new IP subnet used on the multilink between the routers, so no changes are needed to IP addressing.

In real life, you will probably configure SNMP correctly, use a similar configuration on all routers and switches, and then forget the details of how to configure all the other possible options. For the CCNA R&S exams, it helps to make yourself think through the configuration options a few times across the variety of possible settings. This latest lab gives you another change, listing straightforward SNMPv3 requirements with a chance to configure those settings.

Requirements

This lab uses a small network with two routers. Your job is to create a configuration that would work on both routers to enable SNMPv3, per the following requirements:

• Use username Youdda
• Use group name Certskills
• Use text string mysecretpassword for any passwords or keys
• Support reading (Get) the MIB but not writing (Set) to the MIB
• Use the default MIB view (V1Default) if any MIB views need to be configured
• Use an IPv4 ACL named ServerOnly that allows SNMP messages from the one SNMP manager only (172.16.2.9)
• Support Informs, but not Traps, sent to the SNMP manager at address 172.16.2.9
• Use SNMPv3 authentication with SHA
• Use SNMPv3 privacy with 128-bit AES
• As for the topology:
  • Assume all interfaces shown in the figure are up and working, that is, there is connectivity between each router and the SNMP server.

Figure 1: Topology Used for SNMPv3 Labs

Initial Configuration

Examples 1 and 2 show the initial configurations on routers R1 and R2, respectively.

Example 1: Router R1 Initial Configuration

hostname R1
!
interface GigabitEthernet0/1
 no shutdown
 ip address 172.20.1.1 255.255.255.0
!
interface gigabitethernet0/2
 no shutdown
 ip address 172.20.12.1 255.255.255.0
!
router ospf 1
 network 172.20.1.1 0.0.0.0 area 0
 network 172.20.12.1 0.0.0.0 area 0

Example 2: Router R2 Initial Configuration

hostname R2
!
interface GigabitEthernet0/1
 no shutdown
 ip address 172.20.2.2 255.255.255.0
!
interface gigabitethernet0/2
 no shutdown
 ip address 172.20.12.2 255.255.255.0
!
router ospf 1
 network 172.20.2.2 0.0.0.0 area 0
 network 172.20.12.2 0.0.0.0 area 0

Answer on Paper, or Maybe Test in Lab

As always, you should at least answer on paper or by typing in a text editor.

If you do implement this config lab on real gear or some other tool, it is difficult to verify without having an SNMP manager with which to test. The challenge is that the router will accept combinations of commands that fail when trying to communicate with the SNMP manager. For those of you who want to dig a little deeper, and you have at least one router or switch in your home lab, then consider downloading any free SNMP manager. Then make sure your manager can successfully do an SNMP Get to pull information from your router or switch after adding the kind of configuration you build in this lab.

Note that for the purposes of learning SNMPv3, I found that the ManageEngine MIB Browser was a good tool. It gives you enough direct control so that you can see what is happening. However, it may be a more difficult tool to use for someone starting out, in that it requires you to navigate the MIB structure.

Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly. The host info does as well.

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping -c 4 10.1.1.1

Trace example: tracepath 10.1.1.1

To connect to another node within the topology: telnet 10.1.1.1

This lab asks you to use both authentication and privacy with SNMPv3, so it takes a few longer commands compared to some SNMP configurations. Focus on the basics, because there are many basics with SNMPv3 configuration. Especially for this lab, it is very important to try the lab first, to make your brain think through the options.

Answers

Figure 1: Topology Used for SNMPv3 Labs

Example 3: Router R1 and R2 – Identical Config

snmp-server group Certskills v3 priv access ServerOnly
snmp-server user Youdda Certskills v3 auth sha mysecretpassword priv aes 128 mysecretpassword
!
snmp-server enable traps
snmp-server host 10.1.3.3 informs version 3 auth Youdda

Commentary

The four configuration commands show the correct syntax that then matches the logic shown in the requirements. Working through the sample answer’s four commands in the same order as listed in Example 3:

Command 1: snmp-server group

The first command creates an SNMP group, which is a configuration concept which gathers some SNMPv3 parameters for easy reference by the snmp-user user command. It is simply the way Cisco’s team built the SNMPv3 configuration.

The command lists these key parameters:

group Certskills: defines the name of the group with a name that I made up, and that you used based on the requirements for the lab.

v3: keyword that defines the version.

auth: defines that this group performs authentication, but not privacy

access ServerOnly: references IPv4 ACL ServerOnly, which will be used to filter incoming SNMP messages. This ACL matches packet with source address 172.20.2.9, which is the SNMP server’s IP address.

Also, this command can be the starting point for some common mistakes. In this case, note the absence of a write viewname set of parameters, which means that this group does not support writing to the MIB (that is, it does not support the Set command). Also, note that the use of the priv keyword on this command means that both auth and priv must be used on any snmp-server user commands that refer to this group.

Command 2: snmp-server host

The second command completes the work to enable support for Get commands.  This command defines the user (Youdda per the instructions) and links it to the first command. Specifically:

Certskills: refers to the name listed in the snmp-server group Certskills command.

v3: keyword that defines the version.

auth sha mysecretpassword: defines that the user should use authentication, with SHA as the protocol, with a password of mysecretpassword.

priv aes 128 mysecretpassword: defines that the user should use privacy, with AES using 128 bit keys, with a password of mysecretpassword.

Command 3: snmp-server enable traps

The third command is simple: it enables the router to send Trap (and Inform) messages assuming the rest of the related configuration in command 4 is completed. The fourth command is the one that defines whether Traps or Informs are sent (Informs for this lab).

Command 4: snmp-server user

The last command completes the configuration to enable the sending of Inform messages. Traps (and Informs) require that the router know to what IP address to send the Trap or Inform message, that is, the address of the SNMP manager. This command defines the address, and whether to send Traps or Informs, as follows:

host 172.20.2.9: Identifies the IP address of the SNMP manager.

informs: keyword that tells IOS this command is enabling the sending of Inform messages rather than Trap messages.

version 3: keywords that define the version.

priv: defines that the user should both authentication and privacy

Youdda: defines the username (per the snmp-server user command) used for SNMPv3 authentication and privacy.