Posts Tagged ‘Nexus’

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.


If you have upgraded your Cisco Nexus switches to code level 7.0(3)I2(1) or higher and had flowcontrol enabled on an interface, you’ll likely find you’re not able to do a “no flowcontrol receive on” because the command was deprecated. Current recommendation is to default the switch configuration but I have a solution you can implement one switch at-a-time with a single reload to fix this issue:

copy run startup-config
!
copy startup-config <tftp: | scp:>
!
sh run | sed 's/flowcontrol receive on//g' >> bootflash:///no-flow-control-startup-config
!
copy bootflash:///no-flow-control-startup-config startup-config
!
reload
! Do not save the running-config to startup-config - just reload one switch at-a-time

See my video on this very specific topology, what I’ve encountered, and the solution I found to work for me:


There is an issue I have noticed with VMware systems deployed with Nexus vPC technology that involve traffic only making it out of the vPC by disabling half the vPC or getting rid of the vPC completely. Initially you’re thinking this is a Cisco issue and I am here to tell you that you’re wrong.

In the virtual switch port-groups and the VMNIC teaming there is a load balancing algorithm you can choose from. I have seen issues where the VMNICS are set to route based on IP hash but the port-group could be set to something like route based on originating  port-id. 

If you’re noticing that pinging the machine from the vPC enabled switches, if they have a SVI enabled, that the ping is only responsive on ONE of the devices and from a north end machine, outside the vPC and probably your desk, only gets responses when HALF the vPC is down, you need to immediately check the hashing for the vmnics and the port-group.

Use the command: esxtop – to review what virtual machines are using what vSwitch and vmnic port to further aid in your troubleshooting.

I would highly suggest you keep it the same at both levels, there may be only odd circumstances where mixing these is helpful but you’re likely trading predictability for what may be perceived performance you’re probably not getting.


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…


Much like on firewalls you can create object groups in Nexus, which you can utilize when you’re implementing ACLs


object-group ip address {OBJECTNAME}
{subnet/mask}
{subnet/mask}
{subnet/mask}...
exit

ip access-list {ACL_NAME} permit ip addrgroup {OBJECTNAME} [destination]

Makes like simple, huh? What about showing the access-list that has been configured with an object group? Well, under the show access-lists summary you won’t see this, you’ll need to “expand”

show access-lists {ACL_NAME} expanded


Why do VTP in the data center? I have absolutely no explanation for this, it is generally just a bad idea to use VTP to begin with. Perhaps “easy” is one argument, but look at the problems you face with it:

  • Rogue switch with higher revision can screw the network
  • ON some IOS versions, if not all, the VLAN configuration doesn’t reside in the startup-config
  • Rogue switch can be used to gather VLAN information on the network, helping form an inside attack

In a data center you expect a highly available, reliable, and secure computing environment, this is something VTP simply doesn’t offer for a network in the data center. Look at the Nexus lineup, VTP is a feature which is disabled by default! What a great concept, finally! I’ll go ahead and just say it, if you’re using VTP in the data center, you’re just being lazy.


If you are working with the Nexus NX-OS and you want to redistribute static routes into EIGRP you MUST use route-maps. See below on how to use these in Nexus.

Read the rest of this entry »