Showing posts with label howto. Show all posts
Showing posts with label howto. Show all posts

Monday, September 15, 2014

HOWTO: Beat the Capture Portal to Get Your Gadgets Online

The average person has something like 1.5-2 wireless devices according to most studies.  I'm going to extrapolate that the average geek has more on the order of 3.5-4.  When we travel, our gadgets become our lifeline to our normal home life.

On a recent business trip, I left town with my iPhone 5, Nexus 7, laptop, and Chromecast (I only take the Roku on longer trips.).  This trip though was my first with the TP-Link WR-710N travel router.  I bought this on a whim when it came up for cheap on Lifehacker's daily deals.  My initial thought was that I could set it up identically to my home SSID and plug in the hotel's wired port.

At this particular hotel though, there were no wired ports so I had to use another feature of this router.  It has a WiSP (Wireless Service Provider) option for it to use for WAN/Internet.  After configuring the WiSP interface to connect to the strongest AP for the hotel's SSID, I hooked up my laptop to my home SSID and answered the captive portal once.  From there all of the rest of my devices jumped on with no problem.

Another feature of using my own router is that I was guaranteed that communication between my iPhone and the Chromecast would be supported.  Unfortunately there was one downside to the WiSP interface.  It insisted on being configured to connect to only one BSSID which meant if the AP went down it wouldn't roam automatically to a better signal.  I've looked into using DD-WRT instead of the built in firmware to get around this, but so far it seems that this particular model is not DD-WRT supported.  All in all, my solution worked and I look forward to giving it some more road tests.

Tuesday, March 6, 2012

No Port for You! Using Cisco Port Security

Most Cisco switches support a feature known as Port Security.  Port security gives the network engineer the ability to have more granular control as to what device(s) can be plugged into a switch port.  There are a couple of usual use cases for Port Security.

Uses for Port Security

The first use case is to block unauthorized hubs, switches or access points from being used on the network.  In this scenario, Port Security is configured to allow a set number of MAC addresses to come from a certain port.  In most cases it would be set to two, one for the PC and one for the IP phone.  Any MAC addresses past the first two seen would either be denied access to the network or cause the port to be err-disabled (more on the violation modes later).  The allowed MAC addresses can either be statically assigned, dynamically learned, or dynamically learned and made permanent.

The other use case is to ensure that a secure piece of equipment like a credit card reader or biomedical device is the only device able to use the port.  In this case, the port is usually setup for a static MAC address.  Any other hosts are subject to the configured violation mode setup on the port.  If needed, more than one MAC address can be statically assigned to a single port.

Configuring Port Security


Now let's take a look at how Port Security is configured on a switch port.


SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security mac-address 0000.aaaa.bbbb
SWITCH(config-if)#switchport port-security violation restrict
The first command after entering interface configuration turns Port Security on for the port.  Next, the MAC address to be allowed is configured.  Finally the last line sets the violation mode to protect.  There are three modes: protect, restrict and shutdown.
  • Protect - When a violation of the Port Security rules is detected, the port will drop all traffic to the violating MAC addresses and note the violation in the logs.  The port also stops learning MAC addresses even if the violation is only for a VLAN.  As such Cisco does not recommend this mode.
  • Restrict - When a violation of the Port Security rules is detected, the port will drop all traffic to the violating MAC address, note the violation in the logs, and send an SNMP trap. This is the recommended mode from Cisco versus Protect.
  • Shutdown - When a violation of the Port Security rules is detected, the port is put into err-disabled state until either the engineer clears the port or the timer expires if errdiable recovery is configured.
Sticky MAC Addresses

SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security mac-address sticky
SWITCH(config-if)#switchport port-security violation restrict
This example is very similar to the first, but you will notice that instead of a MAC address, the keyword sticky is substituted. This configures the port such that the first MAC address it learns will become the secure MAC address for the port until changed by the network engineer.  All other MAC addresses learned will be considered in violation.  There is an implied default configuration of "switchport port-security maximum 1" in this configuration that limits the port to one mac address learned.  If you wanted to let the port have more than one sticky MAC address, enter the command "switchport port-security maximum <number>".

Aging MAC Addresses

Another twist on dynamically learned MAC addresses is to use aging to limit the number of devices on a port, but not necessarily restrict devices based on the MAC address.  In this configuration the port is set to limit the number of MAC addresses allowed, but as MAC addresses are no longer seen for a set type they are aged out allowing new MAC addresses to be added to the port without a violation.  The aging can either be absolute or based on inactivity.


SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security aging time 480 type absolute
SWITCH(config-if)#switchport port-security violation restrict
In the above example, the port is set to age out a MAC address after 480 minutes go by regardless of activity.

SWITCH(config)# int Gi3/0/27
SWITCH(config-if)#switchport port-security
SWITCH(config-if)#switchport port-security aging time 10 type inactivity
SWITCH(config-if)#switchport port-security violation restrict
This example shows the configuration to have the MAC address aged out 10 minutes after the last activity.

Wrap Up


While Port Security is a very powerful tool, I have not seen it as widely deployed as one would think.  I think part of that is lack of awareness and the other part is fear of taking down a production port automatically.  With the right planning and knowledge, both can be overcome. I really suggest people consider adding Port Security to their port activation templates.  Even if it is just to stop unauthorized hubs, switches and access points, there is definite benefit.

Tuesday, October 18, 2011

NMIS Configuration Part 2

In the previous post I presented a basic how to on configuring the basic notification system for NMIS.  Now I will show how to add network nodes to be monitored by NMIS.  First go to Configuration>System>Nodes.

Configuration>System>Nodes
This will bring up the Nodes listing showing currently configured nodes.  To add a node, click on add to the right of Action on the top right part of the screen.


Once you click Add, you will see the add node screen as shown below.  There are a lot of variables to configure for each node.

  • Name: This is the name of the node and should have no spaces in it.  This must be unique.
  • Name/IP Address:  This is the IP or the FQDN of the node.
  • Group: This is the group in which the node will be displayed.
  • Select Model:  This is the data model that NMIS will use to gather SNMP data from the device.  In most cases automatic works best.
  • Active:  This defines whether the node is currently actively polled.  You can use this set to false to take a group of nodes out of active monitoring without deleting them.
  • Ping: Should NMIS ping the node for availability?
  • Collect:  Should NMIS collect SNMP data from the node?
  • CBQoS:  Should NMIS collect data about Class Based QoS on inbound, outbound, both or none?
  • Modem Calls:  Should NMIS collect data on modem calls (not used often)?
  • Threshold:  Should NMIS run threshold calculations on this node?
  • Rancid: Should the Rancid add in add this node to a rancid configuration file? (I'm not sure if this tool is still supported.)
  • Web Server:  Does this device run a webserver?
  • Net Type:  Is this device WAN or LAN?
  • Role Type:  Is the device core, distribution or access?
  • Depend:  What devices must be up for this device to be up?  This provides NMIS with a way of knowing when not to alert on a node if an upstream node is down.
  • Services: Should NMIS check to make sure certain services are running on the node?
  • Time Zone: What is the time zone offset for the device from GMT?
  • SNMP Settubgs:  What version of SNMP should be used to poll the device and what is the configuration for that version?
When the configuration is complete, click Add and Update node to add the node to the NMIS configuration and tell NMIS to run an initial scan of the host. 


Once the nodes are added, it may take 10-15 minutes for data to start to show up depending on how often the NMIS cron jobs are set to run.  This concludes the basic configuration of NMIS.  There are a lot more nerd nobs in the software, but unfortunately good documentation is not available for the product, especially the newest 8.x versions.  Opmantek has said that documentation is a focus for their team so hopefully it will be coming soon.  In my next post I will discuss how to use NMIS once it is collecting data.

Monday, October 17, 2011

NMIS Configuration Part 1

Since I posted my first article about NMIS, I have had several requests to do a series on how to configure NMIS.  Although I took a break from blogging in September, here is the first in the requested series.


NMIS' configuration is stored in text files in /usr/local/nmis8/conf/ and can be edited by hand.  However, it is highly recommended to use the built in tools to edit the configuration.  The main configuration can be found under Configuration > System > NMIS Configuration.

Monday, August 29, 2011

Cisco Nexus 1000v Roundup

This post is merely an index for the 6 post series I did on the Cisco Nexus 1000v.  I hope that beyond being a good learning experience for myself that it will benefit others. 

Cisco Nexus 1000v - Adding Physical Ports (Part 6)

The previous posts have established a fully configured, but unused Nexus 1000v.  At this point it's like having a physical switch in the rack, powered up and configured, but with no network cables attached.  In VMWare, the "cables" are attached using the vSphere Client.


Attaching Physical Ports to the Nexus 1000v



  1. Connect to vCenter using the vSphere Client
  2. Go to Networking Inventory and select the Nexus distributed virtual switch (dVS).
  3. Right click on the Nexus and choose add host.
  4. Select the host and vmnic(s) to use and change their DVUplink port group to system-uplink (or what you named the system uplinks in your port group on the Nexus) for the system uplink ports and vm-uplink for the VM networking ports.
  5. Click next and choose not to migrate the vmk0 or VMs. (I prefer to verify the Nexus 1000v's operation before migrating anything.)
  6. Click Finish.
  7. Repeat for all hosts in the cluster.
Migrating vmk0 Interfaces to Nexus

Once you have added a few test VMs to the Nexus and are certain that the Nexus 1000v is working properly, it's time to migrate the last physical NIC from the vSwitch to the Nexus 1000v and with it the vmk0 interface used for vMotion and VMWare host management.  Keep in mind that if you don't need this NIC for bandwidth reasons, it is not mandatory to move these services to the Nexus 1000v.
  1. Connect to vCenter using the vSphere Client.
  2. Go to Networking Inventory and select the Nexus dVS.
  3. Right click on the Nexus and choose manage host.
  4. Select the hosts and click next twice.
  5. Click on the destination port group for the vmnic used by vmk0 and choose the Nexus port group.
  6. Click next and then finish without migrating VMs.
You will need to repeat this for each host in the cluster.  Leave the host with the active VSM for last and make sure to migrate it's NICs to the Nexus before disconnecting the vSwitch from the vmnic.  

Friday, August 26, 2011

Cisco Nexus 1000v Software Installation (Part 5)

In this article I will run through installing the Virtual Ethernet Module (VEM) and creating the initial port groups on the Nexus 1000v.

Installing the Virtual Ethernet Module (VEM)

  1. Open the vSphere client and connect to vCenter.
  2. Right click on the host that you are going to install the VEM on and choose Maintenance Mode. (NOTE:  This will vMotion all guests from that host to other hosts if you have vMotion enabled, otherwise those guests will be shutdown.)
  3. Copy the VEM bundle from the Nexus 1000v install zip file to the vMA or to the computer that you are running vCLI on.
  4. Use the vCLI to install the VEM with the following command: vihostupdate -install -bundle <path to VEM Bundle> --server <host IP>
As you can see, installing the VEM software is fairly simple.

Creating the Port Groups on the Nexus 1000v

The Nexus 1000v uses port-profile configurations to define the configuration for each type of interface.  In this part of the install we need to setup profiles for the physical NICs that will uplink to the hardware switch infrastructure for both the system VLANs like VMK0 and the Nexus Control traffic as well as the VM uplinks for normal guest VLAN traffic.  On the Nexus 1000v, physical NICs are all of type Ethernet and virtual NICs are vEthernet.

  1. Connect to the switch management IP address using SSH.
  2. Type config t and enter to enter configuration mode.
  3. Configure a port profile to use for your system uplink ports (VMK0, Nexus Control, Nexus Packet, Nexus Management).  Below is an example:

    port-profile type ethernet vm-uplink
      vmware port-group
      switchport mode trunk
    ! In my lab, 255 is MGMT, 256 is Nexus Packet and Control and 101 is for VMK0
      switchport trunk allowed vlan 101, 255-256
      switchport trunk native vlan 255
    ! This command has Nexus create port-channels automatically
      channel-group auto mode on
      no shutdown
    ! System VLANs come up before the VSM is fully initialized
      system vlan 101,255-256
      description SYSTEM-UPLINK
      state enabled
    
  4. Configure a port profile to use for the VM Guest networks.

    port-profile type ethernet vm-uplink
      vmware port-group
      switchport mode trunk
      switchport trunk allowed vlan 2,102,104-105,259
      switchport trunk native vlan 102
    ! This command has Nexus create port-channels automatically
      channel-group auto mode on
      no shutdown
    ! System VLANs come up before the VSM is fully initialized.
      system vlan 102
      description VM-UPLINK
      state enabled 
  5. Configure port profiles for the guest networking to match the old vSwitch port-groups.

    port-profile type vethernet example-vlan
      vmware port-group example-vlan
      switchport access vlan 
      switchport mode access
      no shutdown
      state enabled
     
  6. Save the new configuration by doing copy running-config startup-config

Now that we have everything configured, the next post will be how to plug the network into the Nexus 1000v.

Cisco Nexus 1000v Software Installation (Part 4)

In the last post, I configured the VMWare stock vSwitch to allow us to start the Nexus 1000v install.  I forgot to mention one thing that I usually do (it's not required) to help with mapping physical ports.  The VMWare vSwitch supports CDP, but is usually set to listen only.  To change it so that it will send out CDP packets you need to do the following:
  1. Using the VMWare vCLI either from a desktop of the vMA appliance run the following command: vicfg-vswitch -server <servername> -B both vSwitch0
  2. Repeate for all of the ESX Hosts in the cluser.
The next step in the Nexus 1000v installation is to install the Virtual Supervisor Module (VSM)  VM appliance(s).

Deploying the Virtual Supervisor Module (VSM)


  1. Download and decompress the Nexus 1000v software from Cisco.
  2. Open up the vSphere Client and connect to vCenter.
  3. Go to File and then Deploy OVF Template.
  4. Select the OVF file under the Nexus 1000v VSM install folder.
  5. Accept the details and the EULA.
  6. Give the VSM a name and choose next.
  7. Choose the ESX data store for the VSM and choose next.
  8. Choose thick provisioned and click next. (NOTE: Thin provisioning is not supported by Cisco for the VSM.)
  9. Map the virtual NICs to the appropriate port groups on the vSwitch.
  10. Power up the VSM and connect to its console using vSphere client.
  11. Once booted, go through the text based administrative setup to configure the following:
    • Administrative user password
    • Role (Standalone/primary/standby)  The first VSM will be primary unless it is to be the only VSM and then it would be standalone.
    • Domain ID.  This number serves to tie VSMs to a VEM and to vCenter.  Each Nexus 1000v instance must have a unique domain ID.
  12. Continue with the basic system configuration including:
    • SNMP Read-Only community string
    • Naming the switch
    • Assigning the management IP address settings
    • Enabling or disabling services.  NOTE: Make sure http and ssh are enabled as they are used later in the process.
  13. Open up a web browser to http://<nexus1000vIPaddress/ and click on "Launch Installer Application" (Requires Java Web Start and doesn't seem to currently work with Chrome).
  14. Give the wizard the credentials for the VSM that you created earlier.
  15. Give the wizard the credentials for accessing vCenter and the vCenter IP Address.
  16. Select the cluster where the VSM is installed.
  17. Assign the proper VLANs to the VSM's virtual NICs by choosing advanced L2 and then chose the proper port groups.
  18. Configure settings for the VSM.
  19. Review the configuration.
  20. Tell the wizard not to migrate any hosts or VMs and let it finish.  It will reboot the VSM multiple times before reporting that it is done.

Friday, August 19, 2011

Cisco Nexus 1000v Software Installation (Part 3)

In this article I will examine the process of configuring the default VMWare vSwitch with the VLANs needed to start the Nexus 1000v Install.


Assumptions: 
·         ESX is already installed
·         vCenter VM is already installed and configured
·         vSphere Client is installed on workstation
·         VLANs for Nexus Packet and Capture interfaces (can be the same VLAN) are created on the network.
·         VLAN for Nexus Management interface is created on the network.
·         The ESXi hosts have their ports configured as trunks with the Nexus Packet, Capture and Management VLANs allowed as well as the VLAN used for the ESX hosts’ IP addresses (VMK0).

The first steps to getting a Nexus 1000v installed are actually to get the basic VMWare vSwitch configured and operating.



Configuring ESXi vSwitch

  1. Open vSphere Client and connect to vCenter.
  2. Click on the host to configure.
  3. Click on the configuration tab.
  4. Click on networking. 
  5. Click on properties.
  6. Click on add.
  7. Click on Virtual Machine and then Next 
  8. Give the network a label and a VLAN ID (0 indicates the native vlan).  NOTE:  This label must be consistent on all hosts for vMotion.
Click finish to complete the process and repeat this on all of the hosts in the cluster being sure to make the network labels identical (case sensitive).  You will need to repeat this for every VLAN that you will need for the Nexus install including the Nexus Packet, Nexus Control and Management VLANs.