As some of you know, I recently jumped off the Windows band wagon and purchased a Mac Book Pro.  I like it, but it’s taking some getting used to.  Recently I wanted to use it to configure a Cisco device via console and realized I didn’t even know where to start.  For Macs being ‘really’ easy, it’s not super clear what happens when you plug in a device that the Mac doesn’t have a driver for.  So I turned to Google, below is what I came up with that seemed to work for me. 

Finding the right driver
This was actually the hardest part.  I’m sure we’ve all seen the very popular USB to COM adapter that looks like this…

image

While they may be branded under many names, I believe they are ,for the most part, all manufactured using Aten hardware.  Mine was the ‘UC-232A’ model.  After trying to get the driver right from Aten and having it not work, I did some googling and came across this site…

http://phaq.phunsites.net/2010/12/13/getting-aten-uc-232a-usb-to-serial-dongle-to-work-on-os-x-snow-leopard/

Apparently finding the right driver is a problem that others are having as well.  At any rate, this guy had a link to a set of drivers that worked for me…

http://phaq.phunsites.net/files/2010/12/osx-pl2303-0.4.1-failberg.pkg_.zip

Download those drivers to your Mac book and install.  Once I did that, I was able to see the device from the terminal…

image

You can see the first time I ran the command I didn’t have the device plugged in.  Once I plugged it in, the USB to COM adapter showed up as a valid TTY device (PL2303-00003014). 

Using the adapter for a terminal session
So now that you have the device installed, how do you actually connect to a a console device?  After more googling, I came across a terminal app called ‘Screen’.  The screen app is what I’ll be using as a terminal emulator to connect to the device console ports.  Once your adapter shows up, connecting is pretty straight forward…

image

All you do is pass the device to the screen app as a parameter and specify your the baud rate.  When you run that you should get kicked to a blank white screen.  Bang, bang the enter key a couple of times and you should be on your device…

image

To exit screen, press ‘CTRL – A’ followed by the letter ‘k’.  This will bring up a message at the bottom of the window that looks like this…

image

Hit ‘y’ and you’ll be dumped back out to the terminal.  Pretty simple right?  After using this for awhile, and not being careful about closing my sessions, I eventually ran into this error…

image

followed by…

image

Pretty obvious here that I forgot to actually close the session to the device.  But if you don’t know what you’re doing a *nix box, this can be frustrating.  Basically, this means that there’s still a copy of screen running that’s holding onto the device you are trying to use (the com adapter).  To fix this, run this series of commands…

 image

Here we run ‘ps’ to tell us about running processes.  From that output, we find the screen app, and then determine it’s process number (far left number).  Then we simply kill the process with the kill command.  Once you do that, you should be back in business!

Making a program out of it
During my googling, I found some people that had made a script to run the app based on some menu input.  This makes things slightly easier so I thought I’d give it a go.  Here’s what I came up with by hacing pieces of other peoples scripts together…

First thing to do is open the AppleScript editor.  This should open a new untitled project.  Paste this code into the window…

set serialDevices to (do shell script “ls /dev/tty.*”)
set theDeviceList to (paragraphs of serialDevices) as list
set theDevice to (choose from list theDeviceList)
set baudList to {1200, 2400, 4800, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
set baudRate to (choose from list baudList default items {9600})
tell application “Terminal”
do script “screen ” & theDevice & ” ” & baudRate
set number of rows of window 1 to 100
set number of columns of window 1 to 80
set background color of window 1 to “black”
set normal text color of window 1 to “green”
set custom title of window 1 to “SerialOut”
end tell

Should look something like this…

image

Then hit the ‘Compile’ button on the menu bar.  This will make it look pretty…

image

Next thing to do is to export the code as an application.  To do this, click on the ‘File’ menu option and select export…

image

On the export menu, give the script a name, and change the file format to ‘Application’.  This will allow you to launch the script as an app…

image

Once you save it, quit the AppleScript editor and double click on the application you just created, you should get a series of prompts that look like this…

image

image

After you pick your device and baud rate, you should see a terminal window launch.  Click on it and hit enter a couple of times…

image

All set!  Just a easier way to select the device you want to use as well as pick the baud rate.  Keep in mind that the same rules apply.  ‘CTRL-A’ plus ‘k’ to quit the session.  A nice free way to use my existing adapter on my Mac!

Tags:

As a matter of personal preference, I was never a HUGE fan of the ASA as a firewall appliance.  For VPN termination, it’s pretty slick but still has some issues.  Either way, I have a 5505 at home that I use for firewall and VPN.  Being bored some time ago (wish I had free time now) I decided to upgrade the device from 8.2 to 9.1 code.  Along with this change came the dreaded ASA 8.3 NAT configuration change.  I’d argue that NAT on the ASA never made true sense, but once you knew how it worked, you could make it do what you wanted it to do.  Not knowing how to configure the new mode of NAT in the CLI, I decided to try it through ASDM (this of course breaking my ‘ASDM is awful never use it’ rule (and yes, I know you have to use ASDM for some of the AnyConnect XML stuff)).  The ASDM configuration lead to the automagic creation of NAT groups I didn’t need, object groups I didn’t need, and ACLs I didn’t need.  Somehow I managed to click enough buttons that it worked, but I wasn’t happy with the end state of the config. 

Fast forward to now.  Now I want to be able to connect to VPN at my house, access local resources, as well as access the internet through my local Comcast connection (internet hairpin).  Thinking this would be straight forward, I pulled down a copy of my ASA config into notepad and realized that it was full of random stuff I didn’t need.  After some clean up, I came to some realizations about NAT on the newer ASA code.  Namely, the fact that you don’t HAVE to use the NAT configuration under the objects themselves.  This, at least for me, was a HUGE help.  Let’s take a quick look at my config so you can see what I’ve setup…

image

So the real goal here is to be able to access a hosting container I use out on the internets from my laptop.  The hosting container only allows certain IP addresses (my home IP) to access it.  So if I could VPN to my house and use my home internet connection to access the hosting space from my laptop, I’d be all set!

In order to accomplish this, you need to do some ‘weird’ NAT configuration. I’m not going to run through my whole ASA config, but here are the important pieces…

hostname ASA
!
ip local pool vpn 10.20.30.249-10.20.30.253 mask 255.255.255.0
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
switchport access vlan 3
!
interface Ethernet0/6
!
interface Ethernet0/7
switchport access vlan 3
!
interface Vlan1
nameif inside
security-level 100
ip address 10.20.30.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address <removed> 255.255.255.248
!
interface Vlan3
no forward interface Vlan1
nameif guest
security-level 50
ip address 192.168.127.1 255.255.255.248
!
boot system disk0:/asa911-k8.bin
!
same-security-traffic permit intra-interface
object network guest
subnet 192.168.127.0 255.255.255.248
object network locallan
subnet 10.20.30.0 255.255.255.0
object-group network VPNPOOL
network-object 10.20.30.248 255.255.255.248
!
nat (outside,inside) source static VPNPOOL VPNPOOL
nat (outside,outside) source dynamic VPNPOOL interface
nat (inside,outside) source dynamic locallan interface
nat (guest,outside) source dynamic guest interface
!
route outside 0.0.0.0 0.0.0.0 <removed> 1
route inside 10.0.0.0 255.255.255.0 10.20.30.117 1
!
telnet 10.20.30.0 255.255.255.0 inside
telnet timeout 1440
ssh timeout 5
console timeout 0
management-access inside
!
dhcpd address 10.20.30.100-10.20.30.200 inside
dhcpd dns 4.2.2.2 8.8.8.8 interface inside
dhcpd enable inside
!
dhcpd address 192.168.127.2-192.168.127.6 guest
dhcpd dns 4.2.2.2 8.8.8.8 interface guest
dhcpd enable guest
!
webvpn
enable outside
anyconnect image disk0:/anyconnect-macosx-i386-2.5.2017-k9.pkg 1
anyconnect image disk0:/anyconnect-win-2.5.3055-k9.pkg 2
anyconnect profiles vpn disk0:/vpn.xml
anyconnect enable
group-policy DfltGrpPolicy attributes
vpn-idle-timeout none
vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
group-policy gp_anyconnect internal
group-policy gp_anyconnect attributes
dns-server value 4.2.2.2 8.8.8.8
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy tunnelall
split-tunnel-network-list value splitvpn
webvpn
  anyconnect profiles value vpn type user
  anyconnect ask none default anyconnect
username <removed> password <removed>
tunnel-group tg_vpn type remote-access
tunnel-group tg_vpn general-attributes
address-pool vpn
default-group-policy gp_anyconnect
tunnel-group tg_vpn webvpn-attributes
group-url <removed> enable
without-csd

Lot’s of config there, but I want to focus on are the bolded lines.  The first bolded line is what tells the ASA to allow the ‘hairpin’ to occur.  Specifically, you are telling the ASA with this command that it’s ok for traffic to come in a interface with a certain security level (0) and leave through an interface with an identical security level (0).  This allows VPN traffic to come in the outside interface encrypted, and leave back out the outside interface to get to the internet. 

The next 4 bolded lines are the NAT configuration.  This is what I’m really interested in…

nat (outside,inside) source static VPNPOOL VPNPOOL
nat (outside,outside) source dynamic VPNPOOL interface
nat (inside,outside) source dynamic locallan interface
nat (guest,outside) source dynamic guest interface

Let’s line these statements up on our diagram to give you a visual of what’s actually going on…

image

The first NAT statement tells the ASA to allow the client space in from the outside interface to the inside interface and to not modify the addresses.  This allows my VPN pool (tail end of my 10.20.30.40/24) to talk to the Local LAN space. 

image

The second NAT statement tells the ASA to take the VPN client space in the outside interface, back out the outside interface, but to dynamically overload it to the outside interface IP.  This is the actual NAT hairpin configuration that allows a VPN client to come in the outside and then leave back out towards the internet with the NAT overload.  

image

image

The last two NATs are simple dynamic overloads for the Local LAN and the Guest LAN network.  This allows both RFC 1918 spaces to be hidden behind the outside interface of the ASA.

Not really a ton too it actually, but I did struggle initially with the NAT until I figured out I could do it without defining the NAT under the object group itself.

Tags: , ,

image

After seeing that Brent had already tackled this on Ubuntu I thought I’d give it a whirl on CentOS.  It took me awhile to figure out the install, but I finally got it running.  Trust me, the time it takes to install this is worth it.  This it pretty cool stuff (If you don’t know what stuff, I’m referring to, check out their web site http://www.opendaylight.org/).

I wouldn’t have been able to get this installed without the walkthrough that Brent posted on his blog.  A large chunk of this is VERY similar to what he’s done with the exception of the OS he used.  THANKS BRENT!

http://networkstatic.net/opendaylight-openflow-tutorial/

Disclaimer: I’ll openly admit that I’m not a ‘Linux guy’.  I hack pieces together and often refer to the googles to help me out.  That being said, this tutorial is what I (the Linux non-expert) did to get this running.  I’m not saying that it’s the ‘right way’ to do it, but I can tell you that it does work. 

I’m going to assume that you have a fresh Linux host available that you can SSH into to start the build.  You’ll need internet access on the host to download the required OpenDaylight components.  That being said, let’s get started!

Note: I’m going to walk through the install process using screenshots.  Due to the sizing of the images, it may be hard to read some of the commands that I’m executing.  If you’re having issues, skip to the end where I include the build script I use.

The first thing you need to do is sign up for an account as part of the OpenDaylight project.  You’ll need this account in order to download a GIT clone of the code.  Browse to this URL…

https://identity.opendaylight.org/carbon/user-registration/index.jsp?region=region1&item=user_registration_menu&ordinal=0

And click on the picture in the middle of the screen to load the sign up page…
image

On the next page, fill in the required information and then click submit…

image

If all goes well, you should see the ‘Success’ message…

image

Now browse to this URL and sign in with your credentials…

https://git.opendaylight.org/gerrit/#/register/q/status:open+project:controller,n,z

image

Once signed in, click on the ‘Settings’ hyperlink in the upper left hand corner of the screen next to your name and email…

image

Under settings, navigate to the ‘HTTP Password’ menu.  Under that menu, you should see your username listed with a blank password.  Click the ‘Generate Password’ button to generate a new random password…

image

You’ll need this account information for the GIT download so just write it down and save it for now.  Now let’s get into the actual Linux install…

As I mentioned earlier, I’m assuming that you have a fresh CentOS installation that we are using.  I’m using a CentOS 6.4 64 bit version of Linux for this example.  So let’s start with disabling the services that cause the most trouble.  SE Linux and ipTables. 

Note: Like I said, I’m not an expert and the end goal here is just to get this running.  Keep your own security best practices in mind when you configure your own host.

Disable SE Linux and ipTables firewall
The first step is to disable SE Linux.  This is done by editing the file /etc/selinux/config and changing the variable ‘SELINUX’ from ‘enforcing’ to ‘disabled’…
image 
image

To save your changes, press the escape key, and then type the letters ‘wq’ followed by the enter key.  This will save the changes you made (write quit). 

The next thing we want to do is to disable the IP firewall.  We’ll stop the ipTables service as well as tell the service not to run at boot…

image

We technically need to reboot the server for the SE Linux change to take effect, but we’ll save that for later. 

Install the pre reqs
Centos uses YUM for package download and installation.  There are a couple of packages that we need to install before we are able to download and install OpenDaylight. First we’ll download and install the individual components…

image

Once you hit enter, YUM will launch the install process and do all kinds of checks and validations for the packages you requested.  Once that is completed, you should get a prompt asking you to approve the actual download and install…

image

Enter yes (y) and press enter.  YUM will kick off the download and install.  Be patient, this will take some time…

image

Once completed, we want want to install a YUM ‘group’.  Specifically, we want to install the ‘Development Tools’ group.  A YUM group is just a group of packages together…

image

Run that command, let it do it’s processing, then approve the install with a yes…

image

Once that’s completed, let’s run a ‘yum upgrade’ to make sure that all our software if up to date…

image

Same deal.  Let it do the processing and then approve the installs…

image

Once that completes, we are done with YUM.  However, we do still need to manually install the Maven software.  To do this, we download the maven package with the ‘wget’ command, unzip it to it’s install location, and then create a symbolic link (shortcut) for it to be instantiated with. 

image

Once the files are unpacked, we create the symbolic link for the ‘mvn’ command…

image

At this point, we’ve installed all of the pre reqs for OpenDaylight.  Before proceeding further, I like to reboot the machine to make sure that I don’t see any issues.  Quick reboot and then we’ll tackle the software build.

Download the code from the GIT repository
In this next step, we’ll actually download the required code from the GIT repository.  To do this, we need to use the login we generated in the first step of this post.  First, make sure you change to whatever directory you want to install OpenDaylight into.  I’ll just use the root directory.  Then, run the following GIT command, enter your password (from the site that you recorded earlier) and wait for the download to complete…

image

Use Maven to install the code
Now that the download is complete, we can use Maven to build the code.  To do so, navigate the specified directory, and then run the ‘mvn clean install’ command…

image

This will take awhile.  Probably right around 10 minutes to complete.  When it’s done, you’ll get some final output that should look like this…

image

Note: If the build errors out and doesn’t complete, make sure the system has enough memory. Brent recommended 1.5 gig in his post and I was having issues getting it to build with 2 gig in a VM.  I cranked it up to 4 and it worked just fine. 

At this point, the controller is ready to run.  However, there is one last setting we have to configure…

Configure the Java variables
OpenDaylight uses some system wide variables as part of it’s run script.  These are considered environmental variables and are what the system uses to find the path to specific files.  The environmental variable we are concerned with is called ‘JAVA_HOME’. Let’s check to see if it’s defined, and then define it ourselves…

image

As you can see, at first the system doesn’t know the variable. Then we use the ‘export’ command to define it. After defining it, the system now knows where it is. To make sure that it persists through reboots, we should also define it in the /etc/environment file…

image

Once the file opens for editing, hit the ‘i’ (insert) key and then type this line in…

image

Once again, hit escape, then type ‘wq’ followed by enter to save the file and exit. 

Fire up the controller
At this point, we are set to fire up the controller.  To do that, browse to the following directory and execute the run script…

image

You should see the application load, and at this point, you should be able to browse to the web app through the URL http://<Server’s IP address>:8080…

image

The default login is admin/admin…

image

We’ll leave it there for now.  I just wanted to get the controller up and running in this post.  Here’s the actual build script I used for the full install…

#Disable SE Linux
Edit the /etc/selinux/config file and restart the server

#Disable the firewall
service iptables stop
chkconfig iptables off

#Install Pre Reqs
yum install  wget vim java ant python eclipse-platform git
yum groupinstall “Development tools”
yum upgrade

#Install Maven
wget http://www.poolsaboveground.com/apache/maven/maven-3/3.0.5/binaries/apache-maven-3.0.5-bin.zip
unzip apache-maven-3.0.5-bin.zip -d /usr/share/
ln -s /usr/share/apache-maven-3.0.5/bin/mvn /usr/bin/mvn

#Get GIT code
cd /
git clone https://blinken_lichten@git.opendaylight.org/gerrit/p/controller.git

#Build with maven
cd controller/opendaylight/distribution/opendaylight/ 
mvn clean install

#Configure Java Env variables
export JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64
edit /etc/environment and add…
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64

#Load the controller
cd /controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-0.1.0-SNAPSHOT-osgipackage/opendaylight
./run.sh

Or if you prefer to see the build script in text file format (no word wrap) just send me a quick email and I’ll send it your way.  In the next post, we’ll talk about connecting the controller to a Brocade MLX switch.  The fun begins!!

Tags: ,

« Older entries