One reason we created these Packet Tracer files to match the book examples is that PT does not always work well with a particular command or feature. You can practice the topics in the CCNA 200-301 OCG Volume 2 Chapter 8 – DHCP Snooping and Dynamic ARP Inspection (DAI) – but PT does have several issues supporting those features. This post helps you re-create the examples from Volume 2 Chapter 8, and points out the issues as well! But you can still learn by trying to re-create the examples.
The big idea is pretty simple: Repeat the Examples in the Official Cert Guide as part of your lab practice for CCNA using Packet Tracer.
The details require some reading. To get your head around what kind of content is here in the blog for these labs, read:
Chapter Intro: A brief description of the topics in that chapter of the book.
Download Link: Links to a ZIP; the ZIP holds all the .PKT files for this chapter.
Table of PKT files, by Example: A table that lists each example in the chapter, with the files supplied for each. Also lists a note about whether the PKT topology matches the book example exactly or not.
Tips: When we build the files, we come across items that we think might confuse you when trying the examples with PT. We write those notes in this section!
Chapter 8 of the CCNA 200-301 Official Cert Guide, Volume 2 discussed two topics related by their overall goals and because of their mechanisms. Both features help secure a network by protecting common protocols against attacks meant to take advantage of those protocols. They are:
Normally, a switch would forward DHCP messages sent by the attached devices, ignoring the fact that some Ethernet frame happened to encapsulate a DHCP message. DHCP Snooping causes the switch to examine the DHCP details, collect data, and make choices. Those choices include filtering DHCP messages that appear to be part of a DHCP-based attack.
A switch configured to use DAI follows a similar process with ARP messages sent by attached devices. The switch would normally forward those Ethernet frames that happened to encapsulate an ARP message, ignoring the ARP details. DAI causes the switch to examine the detail of ARP messages that it forwards. DAI uses a table that lists the legitimate IP address/MAC address pairs, filtering ARP messages that do not conform to that list. DAI uses two types of lists: one statically configured with an ARP ACL, and the other dynamically learned with the DHCP Snooping feature. So it makes sense to learn about DAI and DHCP Snooping at the same time.
When building the content for this post, we review the examples in the book and decide whether it makes sense to supply a Packet Tracer (.pkt) file to match the example. If we choose to support an example by supplying a matching .pkt file, the .pkt file includes a topology that matches the example as much as possible. It also includes the device configurations as they should exist at the beginning of the example.
In some cases, the .pkt file shows two instances of the lab topology – one above and one below. We include two such topologies when the book example includes configuration commands, for these purposes:
|
Example |
.PKT Includes Initial State of Example? | .PKT Also Includes Ending State of Example? | Exact Match of Interface IDs? |
| 08-1 | Yes | Yes | No |
| 08-2 | Yes | No | No |
| 08-3 | Yes | Yes | No |
| 08-4 | Yes | No | No |
| 08-5 | Yes | Yes | No |
| 08-6 | Yes | Yes | No |
| 08-7 | Yes | No | No |
| 08-8 | Not Supplied | Not Supplied | No |
| 08-9 | Not Supplied | Not Supplied | No |
| 08-10 | Not Supplied | Not Supplied | No |
| 08-11 | Yes | Yes | No |
Note: For the entire chapter, the examples show PC1 and PC2, with PC1 as a legitimate user and PC2 labelled as the attacker. In PT, we made PC1 be a DHCP client, with the DHCP server leasing an address that ends in .101. PC2 uses a static IP address in each case.
PT devices do not use the same interface numbering used in the book example. This example uses:
Book SW2 g1/0/2 = PT g0/2
Book SW2 g1/0/3 = PT f0/3
Book SW2 g1/0/4 = PT f0/4
The show ip dhcp snooping output in PT lists shorter output than a real switch, so review the output in the book closely.
Additionally, note that the show ip dhcp snooping output may end with a list of interfaces and related settings. On real switches, the list is meant to list only the interfaces with non-default DHCP Snooping settings so that you can see those settings. PT tends to list all interfaces, regardless of whether they use all default settings or not. The data listed does appear to be correct. So, the issue is about what interfaces the output lists, rather than whether what is listed is correct or not.
See Example 8-1’s notes about the interfaces used with this example.
PT does not support the first two commands in the example (those which begin with errdisable.)
See Example 8-1’s notes about the interfaces used with this example.
PT supports configuring the DAI-related commands in this example, so you can practice the configuration.. However, the switch does not perform the DAI filtering logic, so you cannot test the feature.
PT supports configuring the DAI-related commands in this example, so you can practice the configuration.. However, the switch does not perform the DAI filtering logic, so you cannot test the feature.
PT supports configuring the DAI-related commands in this example, so you can practice the configuration.. However, the switch does not perform the DAI filtering logic, so you cannot test the feature.
Hi Wendell,
I have a question abou DHCP Snooping configuration.
First my question is if you can use SVIs, with dynamic ip allocation, on a switch with DHCP Snooping active (I presume you should in order to manage the sw)?
This is my DHCP lab (with Server, Relay and Clients) where I face an issue:
1 – I set dhcp snooping on a switch that sits on the access side; the sw connects DhcpClients on two Vlans;
2 – the switch has two SVI’s (for each VLAN) and ip addresses through DHCP.
3 – the switch has also a trunk interface towards a router (ROAS topology basically)
4 – on the router are two sub-interfaces with static ip AND for each vlan with #ip helper-address.
5 – ..becaus the router has on another interface/subnet a DHCP server.
Everithing works fine beside the SVI; they dont get any IP addr from the DHCP server if the IP DHCP Snooping is on.
The DHCP Clients are ok with any snooping configuration but again the SVI’s on the switch do not get any IP addr assigned if Snooping is on.
I thank you in advance for your time.
Hi Sorino,
Wow, making me think!
I’m going to have to mull on this one. Some ideas and questions for you:
The access switch is not routing between VLANs. So, it needs only one SVI interface, and need to only be a layer 2 switch. As an experiment, turn off IP routing on that switch, use one SVI, see if that helps.
Also… what models/IOS versions on the devices?
Finally, doing this out of curiosity? I would normally statically assign switch IP addresses, for instance. But I get the need to explore and test.
More later as I get inspiration.
Wendell
Wendell,
thanks for your reply.
Is always full of information.
First thing is that I don’t know for what reason I am creating SVIs for each VLAN?!?
So as I understand I should configure only one SVI for the native vlan, for each Access Switch, that I can use for management. Is that correct?
And I have tried with turning off IP Routing and use only one VLAN but no luck.
I have also tried to create another vlan (vlan 30) and I have not add it to DHCP snooping; than remove all the SVIs and create only one in Vlan 30, set the ip address as DHCP and still no DHCP assignament.
For this lab I’m using CML 2.1 with switch vios-12 Version 15.2.
I will dig more cause I would like to know if DHCP Snooping has any effect on a SW with SVI’s with DHCP enabled.
I will try this DHCP lab on real hardware with C2960 for Access, C3560 for Distribution and two 1921 routers to have a gap between the LAN and DHCP Server.
Thanks again,
Sorin