Tag: General

Posted on

Cisco Route : PPP

By default Cisco uses HDLC encapsulation on Serial interfaces. We are going to setup a simple PPP link with Authentication.

R1#show int serial 0/0   

Serial0/0 is up, line protocol is up

  Hardware is GT96K Serial

  Internet address is 10.1.1.1/24

  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation HDLC, loopback not set

  Keepalive set (10 sec)

  Last input 00:00:09, output 00:00:07, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: weighted fair
R2#show int serial 0/0

Serial0/0 is up, line protocol is up

  Hardware is GT96K Serial

  Internet address is 10.1.1.2/24

  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation HDLC, loopback not set

  Keepalive set (10 sec)

  Last input 00:00:05, output 00:00:06, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: weighted fair

We have to change that to PPP encapsulation on both sides, other wise there will be a encapsulation mismatch and the Interface will remain up but the line protocol will be down.

R1(config-if)#encapsulation ?

  frame-relay  Frame Relay networks

  hdlc         Serial HDLC synchronous

  lapb         LAPB (X.25 Level 2)

  ppp          Point-to-Point protocol

  smds         Switched Megabit Data Service (SMDS)

  x25          X.25
R1(config-if)#encapsulation ppp
R1(config-if)#

*Mar  1 00:05:27.739: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down

R1(config-if)#exit                             

R1(config)#exit

R1#sh int serial 0/0

Serial0/0 is up, line protocol is down 

  Hardware is GT96K Serial

  Internet address is 10.1.1.1/24

  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation PPP, LCP Listen, loopback not set
R2(config)#int serial 0/0

R2(config-if)#encapsulation ppp

R2(config-if)#exit

R2(config)#exit

R2#sh int serial 0/0

Serial0/0 is up, line protocol is up 

  Hardware is GT96K Serial

  Internet address is 10.1.1.2/24

  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation PPP, LCP Open

We should move from HDLC to PPP because PPP has some features that HDLC doesn’t for example, Authentication options, error detection and error recovery features.

Password Authentication Protocol (PAP)  and  Challenge Authentication Protocol (CHAP)

PAP is very passive authentication, where as CHAP actively asks who are you?

PAP also sends username and password in Clear Text.

Here is how to configure CHAP on both routers

The username is the Hostname of the Peer Router you are authenticating to. The passwords must match.

R1(config)#username R2 password TPW

R1(config)#int serial 0/0

R1(config-if)#ppp authentication chap

 

R2(config)#username R1 password TPW

R2(config)#int serial 0/0

R2(config-if)#ppp authentication chap

Most likely if there is a issue its with the passwords mismatching, but you can always use the command:

R1#debug ppp authentication
Posted on

Ruckus : Using Multiple RADIUS Servers

I have recently been configuring Network Access Control with 802.1x, and I had been having issues with using multiple RADIUS servers on Ruckus ICX Switches. The main issue being:

RADIUS Authenticate over SSH to switch using Microsoft NPS RADIUS Server
RADIUS Authenticate using 802.1x or MAC-Auth using DOT1x RADIUS Server

In Ruckus ICX switches there isn’t any concept of AAA groups like in Cisco, where you can designate specific RADIUS traffic to go to various different RADIUS Servers.

I have found 2 work arounds, I did however also call support and spend 1 hour troubleshooting with them and they didn’t have an answer for me.

Some Basic Setup Information

Microsoft NPS RADIUS Server : 1.1.1.1
DOT1x RADIUS Server : 1.1.1.2

Here are my AAA Authentication Commands:

SSH@tpw-sw1# sh run | inc authentication
aaa authentication web-server default radius local
aaa authentication enable default radius local
aaa authentication dot1x default radius
aaa authentication login default radius local

Here are my 2 work arounds:

WORKAROUND 1

SSH@tpw-sw1(config)# radius-server host 1.1.1.1 auth-port 1812 acct-port 1813 default key RADIUS1SECRET
SSH@tpw-sw1(config)# radius-server host 1.1.1.2 auth-port 1812 acct-port 1813 default key RADIUS2SECRET dot1x mac-auth

If you use the 1.1.1.2 RADIUS server first in the list you cannot authenticate to the switch at all, even over super-user-password. So the only way I have it working is to have the DOT1x Radius Server listed 2nd but calling out DOT1x and MAC-AUTH.

WORKAROUND 2

The other method I found is to apply a command at the interface level:

SSH@tpw-sw1# conf t
SSH@tpw-sw1(config)# int ethernet 1/1/1
SSH@tandy-lab-sw1(config-if-e1000-1/1/1)#use-radius-server 1.1.1.2

I hope that this helps, I spent a day trying to figure it out 🙂

 

 

Posted on

The Packet Wizard : Multicast

This week I have been troubleshooting a Multicast problem, before Tuesday I knew the basics of it but I did not realize how deep that rabbit hole went, I can only imagine how deep it goes in CCIE level since it has not really crossed my path in any of my studies thus far. I thought I should write this blog post to share what I have learned this week about Multicast. I will also write another post on how to configure and troubleshoot it.

What is Multicast?

Multicast is a group communication where data packets are sent to a group of receiver/destination computers at the same time. Multicast is one to many or many to many real time communication protocol, where Unicast is one to one and Broadcast is one to all. Multicast is mainly used in IPTV (Netflix, Hulu, Prime Video).

Multicast Address Ranges


They use Class D Range – 224.0.0.0 – 239.255.255.255

224.0.0.0 224.0.0.255 – Reserved for Local Addresses

224.0.1.0 – 238.255.255.255 – Globally Scoped Addresses

232.0.0.0 – 232.255.255.255 – Source Specific Multicast Addresses

233.0.0.0 – 233.255.255.255 – GLOP Addresses

239.0.0.0 – 239.255.255.255 – Limited Scope Address (Similar to Private IP addresses but for Multicast)

 

How does Multicast Work?

The Receiver sends a packet to the Router asking to Join the Multicast Group. Only the clients that want to receive Multicast join what is called a Multicast Group. If the router doesn’t know about it it will send requests out its next hop interface.

Protocol Independent Multicast (PIM) Think of this like a multicast routing protocol sits on top of the Internet Group Management Protocol (IGMP) and builds a pipe back to the source from the destination. There are 3 versions of IGMP:

IGMPv1 – has a 60 second timer and continually asks.
IGMPv2 – can send an I want to leave the multicast group message to the router.
IGMPv3 – can include a source in the join packets.

If the multicast sender has multiple paths to the receiver it will send the multicast multi ways meaning the receiver will receive duplicate messages. The receiver then has to send the reply but it uses the unicast routing table to return the traffic and uses that interface.


Reverse Path Forwarding (RPF) is a check that the receiving device does before the sender sends anything so it knows how to get back to get back to the sender without receiving multiple multicast messages.


Multicast Types

I am sure there are more than two types of multicast but all I have covered are Sparse and Dense mode.

Sparse Mode is like a Join Protocol, where traffic is not forwarded on a segment unless it is explicitly requested. Sparse mode is typically deployed where the receivers are sparsely populated over the network, so that most of the network bandwidth is conserved.

Dense Mode is like a flood and prune system, where everyone receives the traffic until they inform (through the prune system) that they do not want that particular multicast messages. Dense Mode is typically deployed in topologies where listeners are densely populated, but it can be a very chatty protocol.

You can setup sparse mode or dense mode on a per interface basis. Once they are setup and enabled interfaces can run sparse mode while others run dense mode.

A Networking genius (Denise Fishburne – https://www.networkingwithfish.com/ ) said on a training video I watched yesterday “Friends don’t let friends do dense mode”. Denise also recently started following my blog, which is a huge honor. I hope this post is doing some basic justice to Multicast. I am trying to share information I have gathered in the last couple of days. If anyone has any comments or further insight let me know.

 

Posted on

The Packet Wizard : Migrating from Cisco 6500 to Ruckus ICX

Just a quick post this week, I have been busy migrating from Cisco 6500 to Ruckus ICX. Here are some before and after photos and a video of the all important turn off. The main thing I learned in this migration is to chose your ports that are different, do Trunk Ports, Wireless, Printers, anything that is unique or requires a slightly different configuration do them first, then the regular desktop/user ports are just easy swaps.

The before picture we had already started to move the patch panels.

Listen to that power noise drop when it turns off. Turning off Cisco 6500 after Migration

Posted on

Cisco Switch : Private VLAN’s

Private VLAN’s are a very interesting and mostly used for Network segmentation and fun concept but it can take a little to get your head around, so here goes.

Private VLAN’s split a VLAN into Sub-VLANs, called Primary and Secondary.  Secondary VLAN’s have 2 different types :  Isolated and Community.

In this example the Primary VLAN is 100 and the Secondary VLAN’s are Isolated VLAN 200, Community VLAN 300 and Community VLAN 400.

An important port to know about before beginning is called the Promiscuous Port. It acts like a Gateway that routes Primary and Secondary-VLAN traffic, and all Secondary-VLAN traffic must pass through the Promiscuous Port.

Isolated ports can only talk to the Primary VLAN through a Promiscuous Port (Uplink/Gateway Port)

Community ports can talk to each other, if they are in the same Community Secondary-VLAN.

VTP must be set to transparent mode for Private VLAN’s to work.

Here is how to configure Private VLAN’s

First we need to configure the Primary VLAN

TPW-SW1(config)#vlan 100
TPW-SW1(config-vlan)#private-vlan primary 
TPW-SW1(config-vlan)#exit

Configure the Isolated VLAN

TPW-SW1(config)#vlan 200
TPW-SW1(config-vlan)#private-vlan isolated 
TPW-SW1(config-vlan)#exit

Configure the Community VLAN’s

TPW-SW1(config)#vlan 300
TPW-SW1(config-vlan)#private-vlan community 
TPW-SW1(config-vlan)#exit

TPW-SW1(config)#vlan 400
TPW-SW1(config-vlan)#private-vlan community 
TPW-SW1(config-vlan)#exit

Now we have to associate the Primary VLAN to the Isolated and Community VLAN’s

TPW-SW1(config)#vlan 100 
TPW-SW1(config-vlan)#private-vlan association 200 
TPW-SW1(config-vlan)#private-vlan association 300
TPW-SW1(config-vlan)#private-vlan association 400

This is where we configure for fa0/1 as the Promiscuous Port

TPW-SW1(config-if)# int fa0/1 
TPW-SW1(config-if)#switchport mode private-vlan promiscuous

We have to tell the Promiscuous Port that it is associated with the  (Isolated and Community VLAN’s) that it can also see and talk to them appropriately.

TPW-SW1(config-if)#switchport private-vlan host-association 100 200,300,400
TPW-SW1(config-if)#exit

Configure fa0/2 and fa0/7 as the Isolated port, but also about its Primary VLAN 100

TPW-SW1(config-if)# int fa0/2 
TPW-SW1(config-if)#switchport mode private-vlan host
TPW-SW1(config-if)#switchport private-vlan host-association 100 200
TPW-SW1(config-if)#exit

TPW-SW1(config-if)# int fa0/7 
TPW-SW1(config-if)#switchport mode private-vlan host 
TPW-SW1(config-if)#switchport private-vlan host-association 100 200 
TPW-SW1(config-if)#exit

Configure fa0/3 and 4 as community ports, but also about its Primary VLAN 100

TPW-SW1(config)#int range fa0/3 - 4 
TPW-SW1(config-if-range)# 
TPW-SW1(config-if-range)# switchport mode private-vlan host
TPW-SW1(config-if-range)# switchport private-vlan host-association 100 300
TPW-SW1(config-if-range)# exit

Configure fa0/5 and 6 as community ports, but also about its Primary VLAN 100

TPW-SW1(config)#int range fa0/5 - 6 
TPW-SW1(config-if-range)# 
TPW-SW1(config-if-range)# switchport mode private-vlan host
TPW-SW1(config-if-range)# switchport private-vlan host-association 100 400
TPW-SW1(config-if-range)# exit

You can confirm the Private VLAN’s are setup correctly with the following show command

TPW-SW1#show vlan private-vlan

Primary      Secondary    Type                Ports
-------      ---------    -----------------   ----------------------------------
100          200          isolated            fa0/2, fa0/7
100          300          community           fa0/3, fa0/4
100          400          community           fa0/5, fa0/6

Here is the topology of what was just built.

Here is a table of what can talk to each other

PC

Computer PC1 – Isolated – VLAN 200 PC2 – Isolated – VLAN 200 PC3 – Community VLAN 300 PC4 – Community VLAN 300 PC5 – Community VLAN 400 PC6 – Community VLAN 400
PC1 – Isolated – VLAN 200 YES NO NO NO NO NO
PC2 – Isolated – VLAN 200 NO YES NO NO NO NO
PC3 – Community VLAN 300 NO NO YES YES NO NO
PC4 – Community VLAN 300 NO NO YES YES NO NO
PC5 – Community VLAN 400 NO NO NO NO YES YES
PC6 – Community VLAN 300 NO NO NO NO YES YES

 

Posted on

Cisco Router : RIPng

RIP is a IPv4 Routing Protocol and RIPng is an extension of RIP developed to support IPv6. RIP and RIPng are known as Distance Vector Protocols. They use HOP counts as their metric for determining the best path. Here is some basic information for RIP and RIPng

FEATURE RIP RIPng
Advertised Routes IPv4 IPv6
Transport Protocol UDP 520 UDP 521
Multicast Address 224.0.0.9 FF02::9
VLSM Support Yes Yes
Metric Hop Count (Max 15) Hop Count (Max 15)
Administrative Distance 120 120
Routing Updates Every 30 Seconds and with each topology change Every 30 Seconds and with each topology change
Supports Authentication Yes Yes

RIPng is part of the CCNP Route exam, and even although I have not see it used in production, I have however heard of it being used in UNIX environments. It tends not to be used because it is super chatty, its not very scaleable and is based on the Bellman-Ford algorithms which is prone to routing loops and count to infinity issues.

Here is an overview of the basic topology we will be using:

The Steps to configure RIPng:
1. Enable IPv6 Routing
2. Create RIPng Routing Process
3. Enable IPv6 on the interface
4. Enable RIPng on the interface

Here is the configuration steps to enabling RIPng on R1

TPW-R1# conf t
TPW-R1 (config)# ipv6 unicast routing
TPW-R1 (config)# ipv6 router rip TPW_RIP

Complete the steps on R2

TPW-R2# conf t
TPW-R2 (config)# ipv6 unicast routing
TPW-R2 (config)# ipv6 router rip TPW_RIP

You can see the RIPng Routing Protocol is running 

TPW-R1#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip TPW_RIP"
  Interfaces:
    None
TPW-R2#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip TPW_RIP"
  Interfaces:
    None

Although the you can see RIPng is not enabled on any interfaces.

To enable it on the interfaces complete the following commands

TPW-R1#conf t
TPW-R1(config)#int fa0/0
TPW-R1(config-if)#ipv6 rip TPW_RIP enable
TPW-R1(config-if)#int loopback 1         
TPW-R1(config-if)#ipv6 rip TPW_RIP enable

Complete on the 2nd Router

TPW-R2#conf t
TPW-R2(config)#int fa0/0
TPW-R2(config-if)#ipv6 rip TPW_RIP enable
TPW-R2(config-if)#int loopback 1         
TPW-R2(config-if)#ipv6 rip TPW_RIP enable

You can now see the interfaces are running RIPng

TPW-R1#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip TPW_RIP"
  Interfaces:
    Loopback1
    FastEthernet0/0

TPW-R2#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "rip TPW_RIP"
  Interfaces:
    Loopback1
    FastEthernet0/0

Verify all the routes are in the routing table

TPW-R1#show ipv6 route
IPv6 Routing Table - 7 entries
Codes: 
C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1,OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

C   1111::/64 [0/0]     
       via ::, FastEthernet0/0
L   1111::1/128 [0/0]
      via ::, FastEthernet0/0
C   2222::/64 [0/0]
     via ::, Loopback1
L   2222::1/128 [0/0]
     via ::, Loopback1
R   3333::/64 [120/2]
     via FE80::C602:52FF:FE37:0, FastEthernet0/0

Verify on the second Router

TPW-R2#show ipv6 route
IPv6 Routing Table - 7 entries

Codes: 
C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

C   1111::/64 [0/0]
     via ::, FastEthernet0/0
L   1111::2/128 [0/0]
     via ::, FastEthernet0/0
R   2222::/64 [120/2]
     via FE80::C601:52FF:FE34:0, FastEthernet0/0
C   3333::/64 [0/0]
     via ::, Loopback1
L   3333::1/128 [0/0]
     via ::, Loopback1

We need to verify connectivity TPW-R1

TPW-R1#ping ipv6 1111::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1111::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms

TPW-R1#ping ipv6 1111::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1111::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/28 ms

TPW-R1#ping ipv6 2222::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2222::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/2/4 ms

TPW-R1#ping ipv6 3333::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3333::1, timeout is 2 seconds:
!!!!!

Finally, We need to verify connectivity TPW-R2

TPW-R2#ping ipv6 1111::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1111::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms

TPW-R2#ping ipv6 1111::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1111::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/28/28 ms

TPW-R2#ping ipv6 2222::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2222::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/2/4 ms

TPW-R2#ping ipv6 3333::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3333::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/23/28 ms

RIPng is fully configured and working.

Note that using FE80::1 link-local and FE80:2 link-local – for point to point its a lot easier to ping – unique link local on every router and interface, I just wanted to make it a bit easier to see by using 1111::1 and 2, 2222 and 3333

Posted on

Cisco Switch : Dynamic ARP Inspection

Dynamic ARP inspection, starts with a man in the middle attack, with the rogue user and PC sending a gratuitous ARP to say the MAC address for your default gateway is this, then the user accessing anything using the default gateway is sending all its traffic to the rogue users pc, which is then copying all the packets before sending it on to its destination.

 

DHCP snooping must be enabled, for DAI to be enabled.

 

Here is how to configure DAI:

tpw-sw1(conf)# ip arp inspection vlan 10
tpw-sw1(conf)# int gi0/1
tpw-sw1(config-int)#ip arp inspection trust


How to Check and Verify DAI:

tpw-sw1# show ip arp inspection
Posted on

Cisco Switch : Storm Control

Storm Control can shut down an interface that is causing a Unicast, Multicast or Broadcast Storm. It works with Rising and Falling Thresholds. If a specific type of traffic hits the rising Threshold it will block that type of traffic until the number of packets it see’s is below the set falling threshold. This can be in Percentage, Bits Per Second or Packets Per Second

Here is how to enable its various options:

tpw-sw1(conf)# int gi0/1
tpw-sw1(config-int)# storm-control broadcast level 10 5 - this command means if I see more than 10% broadcast traffic I will block until I see it fall under 5%
tpw-sw1(conf)# int gi0/1
tpw-sw1(config-int)# storm-control multicast level bps 20m 10m - this command means if I see more than 20Mbps multicast traffic I will block until I see it fall under 10Mbps
tpw-sw1(conf)# int gi0/1
tpw-sw1(config-int)# storm-control unicast level pps 50k  - this command means if I see more than 50,000 unicast packets per second, I will drop traffic until I see it fall below 50,000 packers per second, that is what happens if you do not put a falling threshold. Both rising and falling threshold is 50,000
tpw-sw1(conf)# int gi0/1
tpw-sw1(config-int)# storm-control action shutdown

Check and Verify

tpw-sw1(conf)# show storm-control broadcast

tpw-sw1(conf)# show storm-control multicast

tpw-sw1(conf)# show storm-control unicast
Posted on

Palo Alto : DNS Sinkhole

The Problem:

We have a infected user and that user is trying to reach out to a command and control server, the infected user does a DNS lookup and since this domain is not hosted locally the internal DNS will pass the request through the Firewall to the external DNS server , the logs wont give all the information we need.

We are going to intercept the DNS traffic between the Internal and External DNS server and respond with a DNS server of our own. Palo Alto send these DNS requests from the infected machines to 72.5.65.111 , which is a Palo Alto assigned address, that will force the traffic to the Firewall to be blocked and logged appropriately.

You do need a Threat Prevention License.

The antivirus release notes will list all the domains that Palo Alto deem to be suspicious.

This is only needed for traffic going to the internet.

How to Configure DNS Sinkhole

Make sure the latest Anti-Virus updates are installed. Device > Dynamic Updates > Click “Check Now”

Configure DNS Sinkhole in the Security Profile Anti-Spyware . Objects > Anti-Spyware under Security Profiles.

Create a New Anti-Spyware Profile or Use an existing one.

Change Action to “sinkhole”

Set Sinkhole IPv4 to the address mentioned above 72.5.65.111
Set Sinkhole IPv6 to the address mentioned above ::1

You then have to apply this security profile to your outbound internet Security Policy/Rule. Select the Rule > Actions > Choose Anti-Spyware Profile

If you want to log who is hitting the sinkhole address you will need to create a deny rule.

 

Commit the Config

Posted on

Cisco Switch : DHCP Snooping

DHCP seems like a seemingly innocent, but common protocol, that can be used against our network. Since we know the DHCP discovery packet is a broadcast packet, just looking for a DHCP server and the host doesn’t care what DHCP server sends a DHCP OFFER back, it will accept the first offer, the DHCP offer includes information such as IP address, Subnet Mask, Default Gateway, DNS information. What if the first offer that is returned is a Rouge or Malicious DHCP server? Does that mean all traffic from that host using the Rogue DHCP servers gateway could be looking at all of the traffic passing through it? Yes! We can prevent this from happening with a feature called DHCP Snooping.

DHCP Snooping is going to snoop or listen into DHCP traffic to make sure that DHCP conversations go to the correct interface and allow that traffic to pass, otherwise it will be dropped. The interfaces to a known good DHCP server will be ‘trusted’ and all other interfaces will be untrusted, therefor the switch will know if DHCP conversations are happening on an untrusted interface then the traffic will be dropped and the interface will be put into err-disabled mode.

By default the switch considers all ports untrusted. We have to enable DHCP snooping globally, then trust at the interface level. IP ARP inspection and IP source-guard are dependent on DHCP snooping being enabled.

Enabled DHCP Snooping 

tpw-sw1(config)#ip dhcp snooping

 

Enable DHCP Snooping on a VLAN

tpw-sw1(config)#ip dhcp snooping vlan 10

 

Trust Interface with DHCP server on it

tpw-sw1(config)#int gigabitEthernet 1/1

tpw-sw1(config-if)#ip dhcp snooping ?

  information  DHCP Snooping information

  limit        DHCP Snooping limit

  trust        DHCP Snooping trust config



tpw-sw1(config-if)#ip dhcp snooping trust

 

DHCP option 82

When packets come in on an untrusted port with option 82 set, those packets are not dropped. The switch will insert its own DHCP option 82 information (the switches MAC address), and when the packet is returned it will make sure its own DHCP option 82 information is in the reply if it is, it will remove its option 82 information and forward the packet normally, if not it will drop it.  This check is enabled by default.

Turn off the validity check

tpw-sw1(config)#no ip dhcp relay information check

 

Turn on Option 82

tpw-sw1(config)#ip dhcp snooping information option

 

Show Commands

tpw-sw1#sh ip dhcp snooping

Switch DHCP snooping is enabled

DHCP snooping is configured on following VLANs:

10

DHCP snooping is operational on following VLANs:

10

DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled

Option 82 on untrusted port is not allowed

Verification of hwaddr field is enabled

Verification of giaddr field is enabled

DHCP snooping trust/rate is configured on the following Interfaces:



Interface                    Trusted    Relay Info policy     Rate limit (pps)

------------------------     -------    -----------------     ----------------

GigabitEthernet1/1        yes                               unlimited