Answers

Figure 1: Lab Topology

hostname Core
!
interface GigabitEthernet0/1/0
  ip address 10.2.11.1 255.255.255.252
  description WAN to R1
!
interface GigabitEthernet0/2/0
  ip address 10.2.12.1 255.255.255.252
  description WAN to R2
!
interface GigabitEthernet0/3/0
  ip address 10.2.13.1 255.255.255.252
  description WAN to R3
!
ip route 10.1.11.128 255.255.255.128 10.2.11.2
ip route 10.1.12.128 255.255.255.192 10.2.11.2
ip route 10.1.13.0 255.255.255.0 10.2.11.2
!
ip route 10.1.21.128 255.255.255.224 10.2.12.2
ip route 10.1.22.128 255.255.255.240 10.2.12.2
ip route 10.1.23.0 255.255.255.0 10.2.12.2
!
ip route 10.1.31.128 255.255.255.248 10.2.13.2
ip route 10.1.32.128 255.255.255.248 10.2.13.2
ip route 10.1.33.0 255.255.255.0 10.2.13.2

Example 3: Core (Router) Config

interface GigabitEthernet0/0
  description R1 LAN interface
  ip address 10.1.13.2 255.255.255.0
!
interface GigabitEthernet0/0/0
  description R1 WAN interface
  ip address 10.2.11.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 10.2.11.1
ip route 10.1.11.128 255.255.255.128 10.1.13.1
ip route 10.1.12.128 255.255.255.192 10.1.13.1

Example 4: R1 (Router) Config

ip routing
!
vlan 11
vlan 12
!
interface GigabitEthernet1/0/1
  description SW1 to PC11
  switchport mode access
  switchport access vlan 11
!
interface GigabitEthernet1/0/2
  description SW1 to PC12
  switchport mode access
  switchport access vlan 12
!
interface vlan 11
  description SVI for VLAN 11
  ip address 10.1.11.129 255.255.255.128
  no shutdown
  ip helper-address 10.1.1.6
!
interface vlan 12
  description SVI for VLAN 12
  ip address 10.1.12.129 255.255.255.192
  no shutdown
  ip helper-address 10.1.1.6
!
interface GigabitEthernet1/0/20
  description SW1 to R1
  no switchport
  ip address 10.1.13.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.13.2

Example 5: SW1 (Switch) Config

interface GigabitEthernet0/0
  description R2 LAN interface
  no ip address
!
interface GigabitEthernet0/0.21
  description Subint for VLAN 21
  encapsulation dot1q 21
  ip address 10.1.21.129 255.255.255.224
  ip helper-address 10.1.1.6
!
interface GigabitEthernet0/0.22
  description Subint for VLAN 22
  encapsulation dot1q 22
  ip address 10.1.22.129 255.255.255.240
  ip helper-address 10.1.1.6
!
interface GigabitEthernet0/0/0
  description R2 WAN interface
  ip address 10.2.12.2 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 10.2.12.1

Example 6: R2 (Router) Config

vlan 21
vlan 22
!
interface GigabitEthernet1/0/1
  description SW2 to PC21
  switchport mode access
  switchport access vlan 21
!
interface GigabitEthernet1/0/2
  description SW2 to PC22
  switchport mode access
  switchport access vlan 22
!
interface GigabitEthernet1/0/20
  description SW1 to R1
  switchport mode trunk

Example 7: SW2 (Switch) Config

vlan 31
vlan 32
!
interface GigabitEthernet0/0
  description R3 LAN interface - unused
  no ip address
!
interface GigabitEthernet0/0/0
  description R3 WAN interface
  ip address 10.2.13.2 255.255.255.252
!
interface FastEthernet0/3/0
  description R1 to PC31
  switchport mode access
  switchport access vlan 31
!
interface FastEthernet0/3/3
  description R1 to PC32
  switchport mode access
  switchport access vlan 32
!
interface vlan 31
  description SVI for VLAN 31
  ip address 10.1.31.129 255.255.255.248
  no shutdown
  ip helper-address 10.1.1.6
!
interface vlan 32
  description SVI for VLAN 32
  ip address 10.1.32.129 255.255.255.248
  no shutdown
  ip helper-address 10.1.1.6
!
ip route 0.0.0.0 0.0.0.0 10.2.13.1

Example 8: R3 (Router) Config

Commentary

This is a BIG lab – it even has BIG in the title. So how do you sift through the configuration? You have two options, and you can use either or both.

First, in this commentary, I’ll hit the highlights. I’ll focus on the most likely places where you might make a mistake or overlook something. But it’s a LOT to think through. Be patient and troubleshoot – you’ll learn a lot by working through as much as you can for yourself.

Second, there’s a Config Lab Review video linked at the bottom of this page. That video breaks down the config, in video form, in smaller pieces. The video first discusses the WAN, then each branch, including its routing, just as I do in this commentary. So it follows the same flow, just with more depth and discussion in the video.

On to the comments! Note that because Step 1 in this lab focuses on learning details about the Core router’s LAN, I did not see the need to comment on it.

Step 2: Configure the WAN Links

Step 2 requires the least work of all the steps. It asks you to configure the three WAN links that connect router Core to the three branch routers. The table lists the subnets, all with a mask of 255.255.255.252, with the direction to use the lower IP address for Core and the higher IP address for the branch. (A mask of 255.255.255.252 results in two usable IP addresses.)

For instance, on the link from Core to R1, Core uses the ip address 10.2.11.1 255.255.255.252 command, while R1 uses the ip address 10.2.11.2 255.255.255.252 command. The other two WAN links follow a similar pattern.

After configuring the IP addresses on both ends of the link, you should be able to ping the branch routers’ WAN IP addresses from the Core CLI. If not, check whether the WAN interfaces are down for some reason and issue a no shutdown command on them as necessary.

Step 3: Branch 1 (Layer 3 Switching)

For this step, begin by thinking about the requirements and configuration for SW1. SW1 acts as a layer 3 switch per the lab requirements. It also connects directly to PC’s 11 and 12, so it acts as a layer 2 switch for those access ports. So, the SW1 configuration requires layer 2 access port configuration plus layer 3 switching configuration.

To support the layer 2 features for the ports connected to PCs 11 and 12, you need to create the two VLANs (for instance, vlan 11). Additionally, the two interfaces connected to the PCs (which you can discover using the CPT user interface) must be configured as access ports and with the correct access VLAN: VLAN 11 for PC11’s port and VLAN 12 for PC12’s port. That completes the layer 2 configuration to support the two PCs.

For the layer 3 switching feature, you need to first enable IP routing with the ip routing global command. Then, you create the SVIs – the VLAN interfaces – using the interface vlan 11 and interface vlan 12 commands. Under those interfaces, you add the IP address configuration per the instructions in the lab. (Note that these IP addresses will be the IP addresses used as the default route by PC11 and PC12, respectively.) I also list a no shutdown command on these VLAN interfaces, based on my experience with CPT, but it may not be necessary.

Don’t forget the DHCP Relay configuration, too! That needs to be added to the interfaces whose IP addresses act as a default gateway. At branch 1, you need the ip helper-address 10.1.1.6 subcommand under the SVIs VLAN 11 and VLAN 12. Without these, the PCs will not be able to communicate with the DHCP server.

But that’s not all at branch 1. SW1, so far, does not have any IP connectivity to the rest of the IP network. The lab asks us to make the R1-SW1 link be routed. That means R1’s interface operates normally, but SW1’s interface needs to be configured as a routed port. Then you configure an IP address on both ends of the link. Per the lab, use subnet 10.1.13.0/24 for this subnet, with address 10.1.13.1 for SW1 and 10.1.13.2 for R1. Note: You must configure the no switchport command on SW1’s G1/0/20 interface to make it a routed port, allowing you to configure an IP address on the port.

Also, to support DHCP clients in these subnets, you need the ip helper-address 10.1.1.6 command, which points to the correct DHCP server. This command should be under the same interface where the default gateway IP addresses are configured – in this case, SVIs VLAN 11 and 12.

Steps 3 and 6: Branch 1 IP Routes

Step 3 details what to do in branch 1, but does not specify anything about IP routes. Step 6 gives details on all static IP routes. I think it’s helpful to go ahead and configure IP routes needed to support branch 1, and then test before working on branches 2 and 3. So I’ll do that here in the commentary.

Step 6 tells us to use static network routes on the Core router for all branch subnets. Branch 1 contains three subnets, all of which are used. The Core router has only a single WAN link to reach branch 1, so the forwarding instructions in the static route should be straightforward to choose. So the static routes for Branch 1, configured on router Core, are:

• ip route 10.1.11.128 255.255.255.128 10.2.11.2
• ip route 10.1.12.128 255.255.255.192 10.2.11.2
• ip route 10.1.13.0 255.255.255.0 10.2.11.2

Note that all three routes have the same next-hop address: R1’s WAN IP address. You could have used the outgoing interface instead of the next-hop address, but it’s better and clearer to use the next-hop address. The three routes on router Core list a unique subnet ID and mask for each of the three subnets.

For routes at the branch, the instructions ask us to use default routes where possible, and when not, to use static network routes. But branch 1 has two devices that are performing routing: R1 and SW1. So for routes on those two devices, first consider routes to destinations in most of the rest of the Enterprise network:

• R1 can use a default route pointing to the Core router as the next hop to forward packets to destinations in the rest of the enterprise.
• SW1 can use a default route pointing to R1’s LAN IP address as the next hop for the same purpose.

That’s what the default route shown in the answer for R1 and SW1 achieves.

Now think about routes on R1 and SW1 for the subnets at the branch. SW1 has connected routes for all three subnets. However, R1 has no connected routes for subnets 10.1.11.128/25 or 10.1.12.128/26. Those subnets are NOT connected to R1 with this design, but rather to SW1 via its SVI interfaces. As a result, R1 also needs two static network routes, one for each of those subnets, pointing to SW1’s IP address, as follows:

• ip route 10.1.11.128 255.255.255.128 10.1.13.1
• ip route 10.1.12.128 255.255.255.192 10.1.13.1

Whew! Yes, that’s tricky, and it’s a lot.

Once configured, you could do some testing. You could use standard and extended pings from router Core, R1, and SW1 to test connectivity to/from each subnet. Also, these routes, along with the earlier work, complete all the configuration required for the branch 1 PCs to fully work. So you could begin by trying all the tests suggested in the lab to see if the hosts can lease an IP address, set other settings, and browse to the web server.

Step 4: Branch 2 (Router-on-a-Stick)

For branch 2, the lab asks us to use router-on-a-stick (ROAS) on the router, with layer 2 features only on the switch. As a result, the layer 2 configuration on SW2 mimics the layer 2 config we see on SW1, this time for the ports connected to PCs 21 and 22. The config needs to create VLANs 21 and 22. It also needs to configure the ports connected to the PCs as access ports and with the correct access VLAN: VLAN 21 for PC21’s port and VLAN 22 for PC22’s port. That completes the layer 2 configuration to support the two PCs.

Before leaving the switch, note that most of the ROAS work happens on the router, but it relies on some switch config. Specifically, the connected switch port must operate as a trunk and use static trunking (because the router will not dynamically negotiate trunking). SW1’s G1/0/20 port uses the switchport mode trunk command to accomplish this.

For the ROAS configuration on router R2, you have options that the lab did not specify. If your ROAS config works, and it differs from mine, great!  However, I made these choices:

• Use the default native VLAN of 1; do not change it.
• Use subinterface numbers that match the VLAN IDs.

Adding those assumptions to the lab instructions, R2’s LAN interface (G0/0) needs to be in a working (up/up) state, but otherwise has no specific config for ROAS – not even an IP address. Instead, the config needs two subinterfaces, one per VLAN, each with the encapsulation (with defines the VLAN) and with the usual ip address command. Here are the commands for one of those subinterfaces:

• interface gigabitethernet0/0.21
•   encapsulation dot1q 21
•   ip address 10.1.21.129 255.255.255.224
•   ip helper-address 10.1.1.6

Of note, the “21” in the encapsulation must match the correct VLAN, but the subinterface number does not. I just chose to use the same number, but you should know which one must match to be ready for the exam.

Also, to support DHCP clients in these subnets, you need the ip helper-address 10.1.1.6 command, which points to the correct DHCP server. This command should be under the same interface where the default gateway IP addresses are configured – in this case, subinterfaces g0/0.21 and g0/0.22.

Steps 4 and 6: Branch 2 IP Routes

Step 4 details what to do in branch 2 except IP routes, and step 6 gives details on all static IP routes. I think it’s useful to go ahead and configure IP routes needed to support branch 2, and then test before working on branch 3.

Step 6 tells us to use static network routes on the Core router for all branch subnets. Branch 2 uses two subnets, with that “as needed” subnet not being needed. The Core router has only a single WAN link to reach branch 2, so the forwarding instructions in the static route should be easy to choose. So the static routes for Branch 1, configured on router Core, are:

• ip route 10.1.21.128 255.255.255.224 10.2.12.2
• ip route 10.1.22.128 255.255.255.240 10.2.12.2

Note that all three routes have the same next-hop address – R2’s WAN IP address – but with the unique subnet ID and mask for each of the subnets.

For routes at the branch, use default routes where possible; otherwise, use static network routes. Compared to branch 1, the concepts are simple. The LAN switch does not perform routing; only router R2 routes. R2 can use a static default route pointing to the Core router as the next hop to forward packets to destinations in the rest of the enterprise. No other static routes are needed at the branch.

Once configured, you can now test the branch 2 PCs. You could use standard and extended pings from router Core and R2 to test connectivity to/from each subnet. Also, these routes, along with the earlier work, complete all the configuration required for the branch 2 PCs to fully work. So you could begin by trying all the tests suggested in the lab to see if the hosts can lease an IP address, set other settings, and browse to the web server.

Step 5: Branch 3 (Router with Embedded Switch Ports)

The design for branch 3 uses a router with embedded Ethernet switch ports. PC31 and PC32 connect directly to ports in the router that behave like switch ports. The configuration then mimics layer 2 config on a LAN switch to support layer 2 features for those PCs. To route packets for the subnets used in those VLANs, the router uses SVIs (VLAN interfaces) with configurations that mimic layer 3 switching on a switch.

First, for the layer 2 features, the router needs commands vlan 31 and vlan 32 to create the VLANs. Note that CPT does not act like real gear and rejects these commands at the current CPT version (8.2.2). Instead, when you configure the switch ports with the switchport access vlan 31 (or 32) command, the router automatically creates the VLAN if it does not yet exist. For this lab, add the switchport access and switchport mode interface subcommands with the correct parameters, and let the router dynamically configure the VLANs.

For the layer 3 switching config, because R3 is a router, you do not need to first enable IP routing with the ip routing global command – it’s on by default. You create the SVIs – the VLAN interfaces – using the interface vlan 31 and interface vlan 32 commands. Under those interfaces, you add the IP address configuration per the instructions in the lab. (Note that these IP addresses will be the IP addresses used as the default router by PC31 and PC32, respectively.)

As usual, add DHCP Relay configuration here, too! That needs to be added to the interfaces whose IP addresses act as a default gateway. At branch 3, you need the ip helper-address 10.1.1.6 subcommand under the SVIs VLAN 31 and VLAN 13. Without these, the PCs will not be able to communicate with the DHCP server.

Steps 5 and 6: Branch 3 IP Routes

Step 5 details what to do in branch 3 except IP routes, and step 6 gives details on all static IP routes. I think it’s useful to go ahead and configure IP routes needed to support branch 3, and then test.

Step 6 tells us to use static network routes on the Core router for all branch subnets. Branch 3 uses two subnets, with that “as needed” subnet not being needed. The Core router has only a single WAN link to reach branch 3, so the forwarding instructions in the static route should be easy to choose. So the static routes for Branch 3, configured on router Core, are:

• ip route 10.1.31.128 255.255.255.248 10.2.13.2
• ip route 10.1.32.128 255.255.255.248 10.2.13.2

Note that all three routes have the same next-hop address – R3’s WAN IP address – but with the unique subnet ID and mask for each of the subnets.

For routes at the branch, use default routes where possible; otherwise, use static network routes. With only one device doing any routing (R3), the routes mirror what we saw at Branch 2. There is no LAN switch. R3 can use a static default route pointing to the Core router as the next hop to forward packets to destinations in the rest of the enterprise. No other static routes are needed at the branch.

Once configured, you can now test the branch 3 PCs. You could use standard and extended pings from router Core and R3 to test connectivity to/from each subnet. Also, these routes, along with the earlier work, complete all the configuration required for the branch 3 PCs to fully work. So you could begin by trying all the tests suggested in the lab to see if the hosts can lease an IP address, set other settings, and browse to the web server.

Known Issues in this Lab

This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:

Why Would Cisco Packet Tracer Have Issues?

(Note: The below text is the same in every Config Lab.)

Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software as real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without owning real devices.

CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.

The lab suggests some basic connectivity checks, focusing on the PCs and the servers. In short, ensure that the PCs – all DHCP clients – have leased an IP address, have the correct default gateway settings respectively, and can communicate with the web server. You should also review the routes on all devices that perform routing to confirm that all the static routes you configured look correct.

If you want to dig a little deeper, you can try these steps.

Use ipconfig /all, ipconfig /release, and ipconfig /renew until all the PCs have leased a correct IP address and have correct settings for their respective default gateways and DNS servers.

Test routes with traceroute/tracert.

1. Record the IP addresses used by each of the PCs.
2. From PC11, issue a tracert for each of the other PCs. In each case, confirm that it works. Then look at each IP address listed and identify the device and the interface on which the IP address is configured. (You can think about this generally, for example, a router WAN interface, or an SVI on a switch.)
3. From each PC, issue a tracert 10.1.1.7 to confirm a working route to the web serverserver.

Connect from each PC to the web server.

1. Open the PCs web browser app.
2. Type URL www.example.com into the browser.
3. Click to go to the web page.
4. If the page does not appear, troubleshoot the problem.