Cincinnerdi Tech Stuff

A mind-numbing read if ever there was one

Archive for the ‘MST’ Category

Mitigating IP DHCP Snooping

leave a comment »

OVERVIEW – Where Cisco’s DHCP Snooping is used to prevent a rogue DCHP server from offering up bad IPs or worse a bad gateway

Lab 03312007

My daughter’s school gives every student two different ID numbers to use. It’s so confusing for her as to which one to use when. In the same manner, allowing a second DHCP on a subnet segment is apt to confuse many host PCs and the users too. Any home router or a Windows Shared Internet or a distro of Linux can easily be setup as a DHCP server, plugged into your network and begin the confusion.

Worse, if a malicious hacker wants to intercept all packets on a network, browse them and send them on their way, setting up a rogue DHCP server, which can define the gateway IP as itself, is one way to do it (i.e., a man in the middle attack.)

Fortunately, Cisco switches allow you to mitigate either the accidental or intentional danger by defining one or more ports on a switch that can be trusted to dole out IP using DHCP. All ports in a VLAN are initially flagged as untrusted for any DHCP offers, then you may indicate which are to be trusted. We will use the global config command ip dhcp snooping to turn it on. Then we’ll use interface commands to set it up for various ports.

I learned a bit more about the somewhat mysterious background workings of DHCP. And frankly, some mysteries continue. Watching WireSharksniff packets provides a clearer idea as to what’s going on. When a client attempts to renew an IP lease (at half way thru its duration) I believe it uses a direct unicast with the original server. If never answered, it will resort to a discover broadcast, trying to locate any DHCP server to offer it an IP. What seems strange though is after a host interface is forced to close down (in Linux with an ifdown command) then brought back with an ifup, the host seems to request the same IP address it had before even if it’s requesting the IP from a different DHCP server. What’s more, if there should be two DHCP servers present (an abnormal and incorrect setup) the host seems to accept (i.e., request) the IP from the original server. This would seem to indicate the need for a hacker to disable the original DHCP server or intercept any of its offers.

Now I overcame this by temporarily disconnecting the Good DHCP server and resetting the host NIC (using ifdown + ifup). The host PC then became responsive to the Rogue server. Note in the Wireshark sniff display below that both 1.1.1.7 (Rogue) and 1.1.1.11 (Good) DHCP servers offered IPs, but in the window below showing the details of the REQUEST packet that it’s accepting the Rogue offer.

Wireshark DHCP

Eric Capal says it’s because the first one doesn’t have to do an ARP request since the original server is still in the host’s ARP cache.

SETUP – Where two DHCP servers are established and the fun begins

  • Setup PC 11 (HD # 07) as DHCP server to dispense IPs 1.1.1.13-250/24
  • Setup PC07 (HD # 01) as DHCP server (rogue) to dispense IPs 1.1.1.201-210/24
  • (Oops, forgot to activate the server in Windows!)
  • Activated MST instead of PVST (see previous post) in an effort to lower the BPDUs. That didn’t work as there’s only 1 VLAN in use.
  • I messed around with Wireshark trying to get some capture filters to work. Need some training here. Want only source (not transmitted or destination) on one PCs MAC.
  • Put both DHCP servers on one net and did some ifdown/ifup commands. Seems a host will go back to its original DHCP server and use it to get its IP. Then if that one is unavailable, it goes to the other and then becomes “loyal” to that one. Capal says that’s because the first one doesn’t have to do an ARP request since that’s still in its ARP cache.
  • I was surprised to see that PC10 was leasing the 1.1.1.252 address after it was not suppose to be able to access DHCP advertisements from the rogue DHCP server. In fact it was NOT in contact with that server, it was merely re-obtaining the 252 IP from the “good” DHCP server. It was its previous IP and it was a valid IP in the “good” server’s scope of IPs. Apparently it requested the “good” server to lease that same IP even though it was originally dealt from the rogue server.

Now for the Show Run and Show IP DHCP Snooping commands: Read the rest of this entry »

Advertisements

Written by scottledyard

2007, March 31st at 8:44 pm

Add VTP and a 1760 router

leave a comment »

Net layout 032407

Maintaining a VLAN database is much easier using VTP, but requires some care about adding a new switch, else it might wipe out your carefully configured VLANS.

I presumed the best way was to setup ONE switch, zap the other switches revision numbers to zero, and then hook them up. But I could have hooked them all up first and then configured. Switches after THAT would have needed to have their revision # set back.

I planned to incorporate the router right into the load balanced, fault tolerant MST (Multiple Spanning Tree) switch network, but ran into a glitch when it came to the router switch ports. The switch banks added into a 1760 router are NOT full function switches, lacking any but VTP transparent mode and NO facility for any STP other than standard. Odd since the IEEE has deprecated STP in lieu of Rapid STP.

I was able to configure the router switch port, a vlan (10) to serve as an IP addressable gateway, a finally ping out to another network (4.4.4.0/24). No small feat since this required the config of the PIX 501 firewall appliances with a static route back to my net. I did get into the config of the PIX enough to see that OSPF routing protocol could be configured to make this simpler and more flexible.

Questions I still have:

An IP is listed for “who” updates VTP on the switch (see note marked ** below). Since the switches update themselves (presumably with layer 2 multicasts) I’m not sure why a layer 3 IP would be important.

VTP Setup.

Let’s take a look at the initial state of VPT on the 3550 switch that I chose to be the “leader” Read the rest of this entry »

Written by scottledyard

2007, March 25th at 10:00 am

Posted in CCNP, Cisco, Cisco Switches, MST, RSTP, STP

Cisco switches: Classic STP -> RSTP -> MST

leave a comment »


To better use switch connections that are otherwise blocked by STP, I setup 5 switches (2 distribution and 2+1 access) to support 7 VLANs with redundant links for fault tolerance.
Traditional CSTP provided for convergence after a link failed, in 52 seconds. RSTP amazingly reduced that to sub-second convergence. MST maintained that, but the lab will continue next time to carry the 7 VLANs over two different virutual switch topologies. (I did NOT use VTP with this work.) Read the rest of this entry »

Written by scottledyard

2007, March 18th at 1:37 pm

%d bloggers like this: