Posts Tagged ‘Catalyst’

DNSMASQ is both a DNS and DHCP server that is quick and efficient to run on Linux systems and is likely already running on your Linux box. If you’re in need of a quick DHCP server to run your environment to serve multiple DHCP scopes for different subnets in your VLAN, of which we all know the best practice is subnet == VLAN == Broadcast domain, then DNSMASQ is your go to guy and I prefer it over the ISC DHCPD server. This quick tutorial will go over the basics of how to get this setup and running and assumes you’re not going to utilize the DNS service.

Create a directory for your DHCP leases file:

sudo mkdir /opt/dnsmasq

Setup dnsmasq.conf:

#
#Disable the DNS server
#
port=0
#
#Setup the server to be your authoritative DHCP server
#
dhcp-authoritative
#
#Set the DHCP server to hand addresses sequentially
#
dhcp-sequential-ip
#
#Enable more detailed logging for DHCP
#
log-dhcp
#
#Set your DHCP leases file location
#
dhcp-leasefile=/opt/dnsmasq/dnsmasq.leases
#
#Create different dhcp scopes for each of the three simulated subnets here, using tags for ID
#Format is: dhcp-range=<your_tag_here>,<start_of_scope>,<end_of_scope>,<subnet_mask>,<lease_time>
#
dhcp-range=subnet0,10.0.0.5,10.0.0.250,255.255.255.0,8h
dhcp-range=subnet1,10.0.1.5,10.0.1.250,255.255.255.0,8h
dhcp-range=subnet2,10.0.2.5,10.0.2.250,255.255.255.0,8h
#
#Setup different options for each of the unique subnets, since default gateways will be different
#The format for this is: dhcp-options=<your_tags_here>,<option>,<option_value> - 3 is router
#
dhcp-options=subnet0,3,10.0.0.1
dhcp-options=subnet1,3,10.0.1.1
dhcp-options=subnet2,3,10.0.2.1

Once this is complete, enable your DHCP service to start automatically. You should also check your systems firewall/IPTABLES service(s) to ensure you have created rules to allow UDP traffic over port 67 and port 68, or you can just flush your IPTABLES and/or disable your firewall, your choice, this isn't a security blog so I'll leave the choice to you, the person who knows their environment better.


We know that for switches to cooperate inside each region the following must be configured the same:

  • Name – Case Sensitive
  • Revision – Any number, but should be the same
  • Instance mappings and their respective VLANs

Now, what about the VLANs themselves? What about switches and security? I looked all over for this answer and it was vague at best and each vendors documentation said something a little different from each others. However, this is just my preliminary testing, I added multiple instances to my spanning-tree setup on my Cisco Catalyst 3750. My scenario was as follows along with the outputs:

  1. Two instances
  2. Instance 1 had all the real VLANs that were actual VLANs on the switch
  3. Instance 2 had 2 VLANs mapped
    • The first test of MIST2 was with both VLANs not being defined on the switch
    • The second test of MIST2 was with one VLAN defined and the other not
    • The third test of MIST2 was with both the VLANs defined

Because MST instances themselves do not communicate the actual VLANs or VLAN mappings, and IST/CIST does not actually communicate the actual VLAN-to-Instance mapping either. Instead, we rely on IST0 to transmit the BPDUs that contain our information like: name, revision, checksum/Config digest/hash and the actual configuration digest/checkum/hash is the value to which each switch will calculate to determine if they’re operating in the exact same region or in different regions. The digest/hash/checksum is calculated based on parameters present in the MST configuration table. Want to know more about the hashing? Here is a link: 802.1s explained.

The information is long and boring, but do a search for “digest” and you’ll find yourself deep into figuring out how this all works. The test results are soon to come, I am working on both Catalyst and Nexus outputs to benefit not just enterprise and branch, but for those in the data center who’re having to work in vPC hybrid environments with STP attached devices. More to come…