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…

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…

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…

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…

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…

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…

followed by…

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…

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…

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

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

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…

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…

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…

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!

The post USB Console adapter on Mac Book Pro appeared first on Das Blinken Lichten.

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…

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…

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. 

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.  

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.

The post Full tunnel AnyConnect with Internet hairpin appeared first on Das Blinken Lichten.

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…

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

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

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

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

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

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…

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’…
 

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…

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…

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…

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

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…

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

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

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

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. 

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

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…

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…

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…

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…

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…

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

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…

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…

The default login is admin/admin…

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!!

The post Installing OpenDaylight on CentOS appeared first on Das Blinken Lichten.

Arguably, this is going to require many building blocks to accomplish.  For instance, let’s take a brief look at OpenStack so I can clarify the difference.  OpenStack is being advertised as a CMS or Cloud Management System.  CMS systems are designed largely to deliver on the promise of IaaS (Infrastructure As A Service).  That being said, to truly deliver IaaS, you’d need to manage all of the pieces of the ‘common infrastructure’ as one logical unit.  This being said, OpenStack provides different components for each application.  The Nova component handles compute, the Swift component handles storage, and the Quantum component to handle the network.  The natural progression of thought here might lead you to believe that Quantum would use OpenFlow to program the network layer.  This assumption would be wrong and the OpenStack example provides an excellent example of the difference between SDN and OpenFlow.  For instance…

While admittedly, this is a VERY basic model I think it makes my point rather clear (also, keep in mind there are other pieces of OpenStack that I’m not showing like the Glance component).  The Quantum component of OpenStack itself leans on what is referred to as a OpenFlow plug-in to talk directly to a OpenFlow controller.  This communication is NOT OpenFlow.  In other words, the OpenFlow plug-in provides an API to an existing OpenFlow controller.  The OpenFlow controller is what talks OpenFlow (depicted with red lines) to any capable OpenFlow switch.  This could be a physical device which I would still consider to be part of the Quantum stack or a Open vSwitch that lives on the compute hardware.  This solidifies my initial statement, OpenFlow is not SDN.  Rather, OpenFlow is a building block of a SDN solution that facilitates the programming of a switching devices data plane.  So without going to much further off course, let’s dive into what OpenFlow is…

A common definition of OpenFlow found on the internet will read something like this…  “OpenFlow separates a switches control and data plane”.

But let’s be clear about that definition.  OpenFlow does not imply that the device’s control plane is now non-existent.  Rather, it means that the source of information which the control plane uses to program the forwarding plane has changed, or been added to.  Traditional (non-OpenFlow) switches rely on control plane processes (BGP, OSPF, etc) to build the switches IP routing table.  From the routing table, the control plane then builds the forwarding table.  The forwarding table is then sent to the data plane so it knows how to forward the frames and packets it is processing. 

In the case of a OpenFlow, the switch get’s it’s information from an external source commonly referred to as an OpenFlow controller.  This device sends flow information to the OpenFlow switch and populates what is referred to as a flow table.  Much like the IP routing routing table on traditional switches, the flow table on OpenFlow switches is then used by the devices control plane to program the forwarding table.  This being said, the data plane doesn’t really change between a standard switch and an OpenFlow switch.  Regardless of where the data comes from (local control plane or OpenFlow controller) the switch still needs to build and maintain a forwarding plane to be able to forward packets and frames. 

This being said a more accurate definition might read “An OpenFlow switch uses a remote source (OpenFlow Controller) to build it’s local FIB”.  More wordy, but also more accurate. 

To understand OpenFlow, we need to understand it’s goal in regards to forwarding.  OpenFlow builds a new data structure on a router called a flow table.  These flow tables can either be proactively or reactively programmed.  That is, they can be pre-populated by a controller or packets can be sent to the controller in order for a forwarding decision to be made reactively.  Both scenarios have their own merits in certain situations but we won’t dwell on that too much in this post.   Just know that the flow table exists and it’s programmed in one of those two fashions for now.

Note: In this post we are focusing on OpenFlow v1.0 since the hardware I’m using currently supports only that version.

Version 1.0 of OpenFlow supports what’s called 12 tuple matching.  A tuple is a fancy computer science term which can really be boiled down to “an ordered list of 12 items”.  The 12 items that the 1.0 spec can match on are…

Ingress Port
Ethernet Source (Layer 2 source)
Ethernet Destination (Layer 2 Destination)
Ether Type
VLAN ID
VLAN Priority
IP Source
IP Destination
IP Protocol
IP ToS
TCP/UDP Source Port
TCP/UDP Destination Port

These 12 items, can be separated into layer 2 specific criteria (blue) and layer 3 specific criteria (green).  I make the distinction here since the particular gear I’m testing on requires that an OpenFlow enabled port either be configured in either layer 2 or layer 3 mode.  That is, it currently only supports matching on one or the other.  This doesn’t truly meet the OpenFlow spec, but it’s a start and I understand the next gen of code (coming this month I believe) will support full 12 tuple matching.  Knowing the limitations that I have, let’s look at an example flow table entry for a layer2 port…

Here you can see a flow entry that’s using the layer 2 information I outline above.  This rule would read like this…

“If a frame enters port 1/4 with no dot1q header, a source MAC of 0024.38a8.a603, and a destination MAC of 0024.38a7.5d01, forward it out port 1/2.”

Pretty simple isn’t it?  As you can imagine, these flow rules can get pretty specific, or be rather generic.  Much like routes to prefixes, the more specific matches will be used first.  

We’ll take a look at some more complex examples in my next set of posts where I cover configuring the Brocade MLX for OpenFlow.  For now, I just wanted to plant the seed as to what OpenFlow is.

The post Defining OpenFlow appeared first on Das Blinken Lichten.

The first interesting piece of the Plexxi solution is the actual hardware.  The current model of the Plexxi switch (PX-S1-R) is a 1U switch advertising 1.28 Tbps of switching capacity.  The switch advertises many standard features such as redundant hot swap power supplies, 32 SFP+ ports, and 2 QSPF+ ports (Sure looks like 4 QSFP+ ports to me but their doco claims otherwise – http://bit.ly/YHiJAZ).  The thing you won’t see advertised on most other 1U switches is what Plexxi is calling the ‘LightRail’ optical interface.  Each Plexxi switch has one of these connections.  The LightRail interface itself is composed of two fiber connections, one labeled, ‘EAST’ and another labeled ‘WEST’…

If you’re thinking ahead, you might have already figured out that these ports are for interconnecting the Plexxi switches.  You might have also figured out that they connect using a ring topology.

The LightRail interface uses a fairly common technology referred to generally as wave division multiplexing (WDM).  Specifically, Plexxi uses CWDM, or coarse wave division multiplexing.  WDM technology allows you to multiplex a range of optical signals onto a single fiber.  Each optical signal uses a particular wavelength within the single physical strand to operate on.  Each of these wavelengths is commonly referred to as a lambda.  CWDM technology generally allows you to use 16 lambdas per physical fiber.  Dense WDM (DWDM) uses tighter channel spacing and generally allows for up to 128 lambdas on a single fiber.  I’m assuming Plexxi used CWDM since it’s cheaper.  CWDM optics can be less precise than those required for DWDM since the channel spacing is much further apart.

In addition to the WDM technology, the light rail interface uses a different connector that what you are likely used to seeing…

This connector is referred to as Multiple-Fiber Push On or MPO.  Plexxi says that this is what they use to make a physical connection between East – West switches.  Specifically, they use a connector that supplies 12 core of fiber (6 pair or 6 RX and 6 TX core) between each switch.  They claim that this gives each interface in the LightRail 120 Gbps of full duplex throughput. 

This is where I got puzzled.  If I have 6 pair of fiber, and with CWDM I can get 16 channels out of a single fiber, shouldn’t I have something like 96 ten gig Lambdas per direction on the LightRail?  I would think so, but it appears that isn’t the case. From what I can tell, they are using CWDM, but only to squeeze two lambdas onto each physical core of fiber.  At this point, why didn’t they just use the 24 core MPO connector?

The answer to that question lies in several places.  It appears that the chief reason at this stage of the game is because they are using the Broadcom Trident 2 chipset in the switch.  From what I can discern from Broadcom’s site, the Trident 2 chip is capable of handling over 100 ten GigE ports.  So I can see this as a possible limitation in terms of actual port termination.  Considering that the Plexxi switch has…

32 – 10 GigE front facing
8 (2(4 x 10GigE)) – QSFP (40 Gig) front facing
12 – 10 GigE east bound LightRail
12 – 10 GigE west bound LightRail

That already takes us up to 64 10 GigE ‘interfaces’.  So there appears to be room there, but I’m assuming it get’s used.  That breakdown points out another interesting fact.  You are talking an almost 2:1 ratio of uplink to access ports.  For a TOR switch, this is pretty impressive. 

The other reason they used CWDM rather than additional physical ports has to do with how the Plexxi switch form a logical topology.  Being able to use wavelengths rather than physical cable gives you all sorts of interesting applications (more on that below). 

Now that we know what sort of bandwidth we have to work with on the LightRail, let’s talk about how it’s allocated.  Let’s look at a base ring topology…

Here we have 12 Plexxi switches in a ring.  The black lines indicate the physical LightRail connections between each device.  Recall that we have 120 gig ,or 12 10 gig interfaces, per direction on the LightRail.  The 120 gig is carved up between what Plexxi calls ‘base lanes’ and ‘express lanes’.  Each switch creates four 10 gig paths to each of it’s directly connected neighbors…

Each green line above represents the base lanes, or 40 gig of bandwidth.  The base lanes provide each switch with four dedicated optical paths to each of it’s directly connected neighbors.  In addition, each switch then creates two 10 gig paths to it’s 4 closest east and west neighbors on the ring.  For ease of visualization, I’ll only show that for one of the switches…

So if we add that all up, we should get 120 gig in each direction…

This topology is what is referred to as a chordal ring.  More specifically, this base topology would be considered a 10 degree chordal ring.  10 degrees since each node has 10 connections to other nodes in the ring.  Keep in mind that this is just the base topology, AKA you just booted up the Plexxi ring.  This is not static and can change to better fit the applications running on top of Plexxi (more on this soon).  As you can imagine, this lends itself to all kinds of interesting logical topologies that the ring can use. 

So now that we know about the switch to switch connectivity, let’s talk about what happens to actual data entering a switch.  As we discussed above, the switches are based off of the commodity Broadcom Trident 2 chipset.  So there are really three main components to a Plexxi switch. An optical module (handles the WDM and LightRail), the Broadcom chip (for the actual ‘switch’ processing), and a crossbar fabric to connect the two.  When traffic enters a switch, it can do one of three things.  Either it can head to the Broadcom (access ports), optically bypass the switch, (on it’s way around the ring somewhere else), or it can be optically switched to another wavelength.  The crossbar can be programmatically manipulated to send incoming traffic wherever it’s needed. 

So it’s a safe assumption then that incoming wavelengths can be programmed to either terminate on the switch (end access port for host) or get optically switched outbound to another Plexxi switch.  Confused?  For now just keep the following fact in mind.  Despite the fact that the physical cabling is a flat ring, you are really working with a ‘full’ optical mesh.  In a design with 11 Plexxi switches, each switch would have direct connectivity to every other switch in the ring. 

Now that we’ve talked about the hardware used, let’s talk about the second interesting piece of the Plexxi solution.  The software.

What makes Plexxi a true SDN solution is the software that manages this hardware.  Above all of the hardware sits Plexxi control.  But before we talk about the control, we have to define the term ‘affinity’.  If you’ve read any Plexxi doco up to this point, you’ve probably heard the term being used.  Plexxi defines an affinity as ‘referring to the relationship between data center resources required to execute a given application workload’.  So basically we are talking about all of the components required to make an app in a data center work.

Traditional data center design (for the most part) strives to make the network an even playing field for applications.  Since servers (and other services) can generally be deployed anywhere within a DC (or between DCs), we need to build the network in a manner that makes it ‘fair’ for all devices.  Since the network isn’t dynamic, this leads to some degree of network ‘waste’.  If we want the performance between A and B, and we don’t know what switch A and B will connect to, we better make sure that all paths will be good performers.  This is of course, is not always the case.  Certain apps get built with the network in mind.  That also implies that the network is being engineered specifically for this use case, and once built, is once again static in nature. 

Plexxi aims to change that.  Rather than trying to make a fair playing field for all devices all the time, Plexxi think you should do the opposite.  You should pinpoint what services an application uses and logically group them together.  To Plexxi, this set of resources would be considered to be an ‘affinity group’.  Once we identify the affinities, we can manipulate the network dynamically to better suit given affinity groups.  Plexxi likes to say that this means you are ‘starting from the top down’.  Meaning you are starting with app requirements and then building a network that fits those needs.  This being said, the heart of the Plexxi solution is the control which Plexxi aptly named ‘Plexxi control’.  The control solution has 3 major tasks.  Workload modeling, network fitting, and global network control. 

The workload modeling component is what’s used to build an understanding of what’s running on the network.  From the sounds of it, this piece of control soaks up information from as many sources as it can to try and build a complete picture of what’s running on the network.  From this information, it can start to establish network needs and affinities as it sees them on the actual forwarding plane. 

The network fitting component acts on the data which the modeling component gathered.  Analyzing all of the known affinities the fitting component determines what the best network topology is to fit all of the affinities.

The global network control component seems like a fancy way to say that the Plexxi switches aren’t totally reliant on the controller.  Each Plexxi switch is actually a ‘co-controller’ and is capable of making some of it’s own decisions.  This allows the network to react to link failures with the controller offline.

While I haven’t seen much of Plexxi control yet, that will obviously be the key to this solution.  The hardware seems interesting and I’m sure it will get more interesting as the platform takes off.  While this all seems promising, I do have a few reservations about the concept in regard to the depth of the affinities.  What I mean by that is, the affinity can only go so far.  For instance, consider a large blade or blade/chassis server deployment.  It would not be uncommon to see 8 chassis of 8 blades hanging off of a data center switch.  Running on those servers we could very easily have over 1000 VMs.  The network aggregation point for those servers will likely by a rather small number of 10 gig uplinks, likely less than 10.   Duplicate that design a few times, tack on a self provisioning portal for VM’s that works off of open capacity in the compute pool, and I’m starting to see a problem.  Applications can be deployed anywhere, and while I have no doubt that Plexxi can find some valid affinities, how useful would they be?  You are dealing with possibly hundreds of affinities, and thousands of server, but only 10 uplink ports.  How much can you optimize the physical network when your aggregation point for so many servers is just a few ports.

On the other hand, maybe there is something that Plexxi could do with that.  Or maybe that exact solution isn’t a good fit for the product.  Either way, I can certainly think of lots of other use cases for a network mesh that can dynamically change.  That ,in and of itself, is definitely a huge win.

As always, looking for feedback and comments. 

The post Plexxi – Layer 1 SDN appeared first on Das Blinken Lichten.

The post OpenStack Quantum Presentation appeared first on Das Blinken Lichten.

And now for a quick rant on the ‘networking community’. 
GET INVOLVED!  While it might be hard to believe, there is a VERY active networking community out there.  It’s not hard!  I started my blog in November of 2009.  My first post was on how to configure guest wireless on a base license ASA security appliance.  And I was running my blog on this…

That is an old Pentium 4 computer I found in a dumpster somewhere.   It’s running CentOS with WordPress on top of it.  I had to learn at least basic Linux to get the thing working (another learning experience!) and I’ve been using the box ever since.  Should I upgrade?  Maybe, but that’s not my point.  You don’t even have to go this far, if you don’t mind having a URL like blog.wordpress.com you can do this for FREE!  All it takes is your time! 

A tweet that Ethan Banks (@ecbanks) sent yesterday sort of brought my thought process on blogging full circle…

And while your at it, write a blog entry on it!  I can’t tell you how much blogging has helped my learning process.  I’m a firm believer that sometimes you just need to hear an explanation phrased in a different way for it to make sense to you.  There are likely thousands of blog entries out there on how to configure private VLANs on Cisco gear.  Does that make them redundant or unnecessary?  I’d argue that some of the blog posts out there make WAY more sense than Cisco’s documentation.  It all depends on how you learn and how your brain processes the concepts.  Another plus of blogging is having a public online archive of what you’ve been studying and working on.  Forget how to do something?  Have internet access?  Just look it up!

I’ll admit, there were times over the last 3+ years where I neglected the blog entirely.  Stuff happens, but I think you’ll find that once you start blogging, and really get involved, it becomes an addiction.  I love blogging now.  Why?  Because I’m involved in the community.  Here’s an example.  I posted an article on how to configure standard and extended ACLs based on my CCIE studies.   Within hours of posting I get a comment from Paul Stewart  (@packetu) over at Packet University…

And just like that, something came up that hadn’t ever occurred to me.  The networking community is about so much more than just blog posts.  It’s about having a community of people who are REALLY interested in networking that you can communicate with, bounce ideas off of, and learn from. 

And you don’t have to be an expert to get started.  I had just just gotten my CCNA 4 years ago when I started blogging and all I had was a strong interest in learning more about networking.  4 years later I’m sitting on my couch studying for me CCIE and I get an email from Stephen Foskett (@sfoskett) asking if I want to come to a Networking Field day event. 

My point is that you should get involved.  Trust me, if you are interested in getting involved, you’ll be more than surprised by the experience.  So if you’re interested in becoming part of the ‘networking community’ but don’t know where to start, just reach out!  We’re all here to help you get started and everyone that’s involved loves it when the community get’s bigger.

End ‘networking community’ rant

Now that my rant is over, let’s talk a little bit more about the actual event.  If you’ don’t know what Tech Field days are, the Tech Field Day site is a great place to start…

http://techfieldday.com/about/

http://techfieldday.com/faq/

Basically, delegates from across the blogging community get invited to the events by Gestalt IT.  Vendors have blocks of time in which they can talk to us about new technologies, new products, and ask for feedback.  The whole idea is to connect people together.  You ,as a blogger, get the chance to talk to the real subject matter experts at some of the vendors which is something that doesn’t happen as often as it should. 

Another neat thing about Tech Field Days is that they are streamed live.  That is, even if you aren’t there in person , you can watch the stream live and interact with the delegates through twitter or other social media.  In addition, the videos are then professionally edited and posted online for you to view later.  Here’s a quick run down of the vendors that presented and their associated recordings…

Cisco Data center and Borderless
Cisco OnePK

What is Cisco onePK? from Stephen Foskett on Vimeo.

Cisco OnePK and Puppet

Using Puppet with Cisco onePK from Stephen Foskett on Vimeo.

Cisco One Controller

Cisco one Controller History, Future, and Use Cases from Stephen Foskett on Vimeo.

Cisco Catalyst Dual VSS

Cisco Catalyst 6500 High-Availability Features from Stephen Foskett on Vimeo.

Cisco 3850

Cisco Catalyst 3850 Converged Access Switch Overview from Stephen Foskett on Vimeo.

Cisco 3850 Demo

Cisco Catalyst 3850 Converged Access Switch Demo from Stephen Foskett on Vimeo.

Cisco Store-In-A-Box

Cisco Store-in-the-Box Demo with Kishan Ramaswamy from Stephen Foskett on Vimeo.

Cisco Identity and OnePK integration

Cisco DC Mobility

Cisco Private Datacenter Mobility Demo with Mostafa Mansour from Stephen Foskett on Vimeo.

Stephen Foskett leading the Cisco Idol competition

Stephen Foskett Presides Over Cisco Borderless Idol from Stephen Foskett on Vimeo.

Cisco In depth DC mobility discussion

Cisco Private Datacenter Mobility in depth with Mostafa Mansour from Stephen Foskett on Vimeo.

Cisco Wired and Wireless Demo

Cisco Wired and Wireless Demo from Stephen Foskett on Vimeo.

Free-From discussion on SDN and hybrid Switching

Free-Form Discussion on Hybrid Switching, OpenFlow, and SDN with Cisco from Stephen Foskett on Vimeo.

SolarWinds
Intro and General Overview

SolarWinds Introduction and Portfolio Overview from Stephen Foskett on Vimeo.

Network Management

SolarWinds Network Management Update from Stephen Foskett on Vimeo.

SWiS API Intro and Demo

SolarWinds SWiS API Introduction and Demo from Stephen Foskett on Vimeo.

Free product offerings

SolarWinds Free Products from Stephen Foskett on Vimeo.

Ruckus Wireless
Introduction to the Wi-Fi market and Ruckus

GT Hill Introduces the Wi-Fi Market and Ruckus Wireless from Stephen Foskett on Vimeo.

Wi-Fi channel and protocol discussion

Sandip Patel of Ruckus Wireless Places 802.11ac in the History of Wi-Fi from Stephen Foskett on Vimeo.

Brocade
Welcome and Introduction

Mike Schiff Welcomes Networking Field Day 5 to Brocade from Stephen Foskett on Vimeo.

OpenFlow and ONF Discussion

Brocade OpenFlow and ONF Update with Curt Beckmann from Stephen Foskett on Vimeo.

MLXe and OpenFlow discussion

Brocade MLXe Router and OpenFlow Hybrid Port Mode from Stephen Foskett on Vimeo.

Vyatta Update

Brocade Vyatta and Software Networking from Stephen Foskett on Vimeo.

Macro Trends in Networking

David Meyer on Macro Trends in Networking and the Role of SDN from Stephen Foskett on Vimeo.

Plexxi
Plexxi Introduction

Mat Mathews and Derick Winkworth introduce the Plexxi Presentation at NFD5 from Stephen Foskett on Vimeo.

Plexxi technology overview – WDM

Marten Terpstra Describes How Plexxi Brings WDM To The Datacenter from Stephen Foskett on Vimeo.

Affinities and applications

Simon McCormack Details How Application Relationships Drive Plexxi’s Controller from Stephen Foskett on Vimeo.

Juniper
Puppet for JunOS

Jeremy Schulman Introduces Puppet for JunOS from Stephen Foskett on Vimeo.

Puppet Demo

Jeremy Schulman Outlines a JunOS Puppet Run from Stephen Foskett on Vimeo.

Juniper Next Gen sneak peak

A Sneak Preview of Juniper’s Next-Generation Programmable Core Switch from Stephen Foskett on Vimeo.

Contrail Discussion

Parantap Lahiri Presents Juniper Networks’ Contrail VNS from Stephen Foskett on Vimeo.

WebApp secure demo and discussion

Juniper Webapp Secure Introduction with Kevin Kennedy from Stephen Foskett on Vimeo.

So there you have it.  I love the idea of being able to go back and view pieces of the actual presentations when I’m looking at a particular technology later on.  A quick side-note on that topic.  There is A LOT of content here.  Many delegates explain the event as ‘drinking from the fire hose’.  That’s totally true.  There were lots of technologies discussed that I plan on spending a lot more time looking at.  However, that’s going to take time.  I fully expect to be generating NFD5 related posts for the next 3 or 4 months at least.  Since I like to write more about the ‘hands on’ application of these technologies it tends to take more time, especially since all of this stuff is cutting edge. 

The other huge plus of attending NFD5 was meeting some truly awesome people.  Not only from the vendors, but the other delegates and Tech Field day staff.  If you don’t currently follow these people, do so now…

Brandon Carroll – http://techfieldday.com/delegate/brandon-carroll/

Brent Salisbury – http://techfieldday.com/delegate/brent-salisbury/

Collin McNamara – http://techfieldday.com/delegate/colin-mcnamara/

Ethan Banks – http://techfieldday.com/delegate/ethan-banks/

Greg Ferro – http://techfieldday.com/delegate/greg-ferro/

John Herbert – http://techfieldday.com/delegate/john-herbert/

Josh O’brien – http://techfieldday.com/delegate/josh-obrien/

Paul Stewart – http://techfieldday.com/delegate/paul-stewart/

Pete Welcher – http://techfieldday.com/delegate/pete-welcher/

Terry Slattery – http://techfieldday.com/delegate/terry-slattery/

Tom Hollingsworth – http://techfieldday.com/delegate/tom-hollingsworth/

Stephen Foskett – http://techfieldday.com/delegate/stephen-foskett/

Claire Chaplais – http://techfieldday.com/delegate/claire-chaplais/

I was admittedly a little nervous meeting all of these people.  I mean, this is a list of some of the smartest people in the networking industry.  They were all amazing people to meet.  I was more than honored to meet them all and look forward to continued contact going forward. 

So that’s it.  I wanted to get my first NFD5 post out there (along with my ‘community’ rant) to get things started.  I’m taking a month or so off from CCIE studying to focus on blogging so expect some more NFD related posts in the coming weeks. 

The post My first Networking Field day #NFD5 appeared first on Das Blinken Lichten.

It’s becoming rather apparent that I ‘over-prepared’ for the exam.  I started studying casually for the CCIE after wrapping up my CCIP cert back in December of 2011.  Casually to me means slowly reading through Odom’s CCIE cert guide.  Now the problem is that casual studying really doesn’t work for me.  I tend to lose focus unless I have an outline and some end goal.  So back on February 18th I booked the exam.  Having the date on the calendar really lit a fire underneath me to get things done.  So here’s how I tackled the exam prep.

Exam Prep
-I printed a copy of the blue print for tracking my progress.  If I was comfortable enough with a topic or section I highlighted it right away so I wouldn’t waste any time messing around with it.  Then as I completed sections I highlighted them to track my overall progress. 

-I read Odom’s book cover to cover over the period of a month.  As I read I’d start filling out a page in a notebook with topics that I wasn’t comfortable with or wanted to see work in the lab.  My rule was that once I got a full page, I’d stop reading and go to the lab to work through the items I had noted down.  Once I finished the reviewing the page, I went back to the book and repeated the process.

-The Odom book is a great ‘topic refresher’ ,but in my opinion, doesn’t have enough details to take a reader from novice to expert.  There were lots of blueprint topics that only had a brief mention, a page or less of content, in the book that really wasn’t sufficient.  When needed, I supplemented the Odom book with others.  These were the books I ended up reading cover to cover…

CCIE Routing and Switching Certification Guide (4th Edition)
Routing TCP/IP, Volume 1 (2nd Edition)
Interdomain Multicast Routing

The multicast book was sort of a ‘I’m really interested’ purchase and not necessarily required, but I think it’s a book worth having (Big thanks to Kurt Bales for the recommendation many months ago!).  The first two books are definitely required reading though.  I also used the internets to supplement some comment.  If you google something like ‘CCIE spanning-tree’ you can usually find all kinds of blogs created by other CCIE candidates that have great answers and explanations.  I’m a big believer in the fact that people need to hear concepts in different ways to understand them their own way. 

-I labbed everything I could.  Not only did  I lab it, I spanned and analyzed the actual packets hitting the wire.  This was, without a doubt, the best way that I learned about how the protocols worked.  Often times I’d read something and think to myself that I completely understood the topic.  Then I’d configure it, and when I saw the actual packets I would be completely amazed at how much I had misunderstood (or just missed pieces) the protocol just by reading about it. 

Practice Tests
I don’t generally like doing practice tests until the very end of my studies.  I find them sort of distracting and it’s really easy to get off path by using them.  In the last week of study I installed and used the Boson exam that came with the Odom book.  To be frank, I found it useless.  There were at least two questions that were completely wrong and many that were worded in a such a way that they were almost impossible to answer.  To top it off, the explanations were awful.  In my opinion, don’t waste your time.  Rather, someone from work recommended to me the Boson exam questions that you can actually purchase from Boson…

http://www.boson.com/practice-exam/350-001-cisco-v4-ccie-practice-exam

These questions were MUCH better.  The questions were well thought out, the explanations were amazing, and I felt like it gave a much better idea of the actual type of question you might see on the exam. 

The key to successfully using practice exams (in my opinion) is to not only understand the correct answer, but to also understand why the other answers were wrong.  I found that by doing this, the questions were very helpful.  Also, when I added them to my cart there was a button that said something like ‘special offers’ next to the checkout button.  When I clicked on that, I found a $20 coupon off so I got them for $80.  I think I got the discount for registering the Odom book first but I’m not sure. 

The Exam
The exam itself is like any other Cisco exam.  You NEED to take your time, go slow, read EVERY possible answer (even if you think A is the right one for sure), and double check the final answer.  Beyond that, there is a strategy I use generally on multiple choice tests that I can share with you. 

In college, there was a professor I had who made the worst multiple choice exams.  You know, the ones that had had 7 possible answers and E and F were combinations of A, B, C, and D (ex: F  – Answers A and C).  After doing poorly on an exam I went to his office and complained that the answers were too vague and it was hard to discern which one(s) were the right answer.  He explained to me that there was a simple way to pass his exams.  All I had to do was work backwards.  Rather than finding the right answer, all I had to do was get rid of the ones that I knew were wrong leaving only one answer.  If for instance I could prove that A was wrong, I knew that F (Answers A and C) was also wrong. 

On Cisco exams, I use this approach often.  Not only because they can sometimes use tricky wording, but it also helps me ensure that I actually read all of the questions so I don’t miss something. 

That’s all I’ve got.  I can’t say for sure my study method would work on it’s own, but it worked for me.  I’m looking forward to a couple weeks off and then starting in on the lab prep.  If anyone’s got any advice on that front, I’d LOVE to hear it!

The post CCIE Written – Observations appeared first on Das Blinken Lichten.

Imagine a topology like this one.  Here we have 4 routers that are using static routes to get to non-directly connected networks.  In this case, I made the routing asynchronous by having router1 go through router2 to get to the 10.0.0.8 and 10.0.0.12 networking.  Similarly, I made router4 go through router 3 to get to the 10.0.0.4 and the 10.0.0.0 networks. 

Let’s do a very basic check to show the basics.  Here we will configure the uRPF check on router1’s vlan 20 interface (10.0.0.5)…

This is pretty straight forward.  It says to check packets coming this interface with a RPF check.  If it fails, drop the packets.  We can see the results of applying the check by trying to ping one of router1’s interfaces from router4…

So that’s really the main point of the configuration.  The router checks to see if it would use the packets arriving interface as the return interface.  If the check fails, the packet get’s dropped.  We can see the drops if we look at the fa0/0.20 interface on router1…

So that’s the ‘basic’ way to configure uRPF.  Now let’s take a look at some examples of how to configure some of the other options.

uRPF processing works in an order like this…

-Do the RPF check, if it passes forward the packet
-If the check fails, check for associated ACL
-If ACL exists, check to see if packets match ACL
-If ACL match exists, forward packets regardless of uRPF

Note that we specify an ACL here.  If you were looking at a router and hit the ‘?’ when configuring the uRPF check the firs time, you would have seen this…

Let’s configure 2 ACLs and see if we can get them to work…

Let’s apply them one at a time to our uRPF check and see what we get…

A quick test from router4 shows that we can ping both of router1’s interfaces…

Looking at the fa0/0.20 interface on router1, we can see that the matches on the interfaces are now showing up as ‘suppressed verification drops’.  We can also see that it’s configured to allow access to communication that matches the ‘reachable-via RX’ condition, or that match ACL1…

Let’s clear the counters and configure the extended ACL to see what happens…

Pings from router4 now act differently…

The pings to 10.0.0.5 aren’t working while the pings to 10.0.0.1 are.  Looking at our extended ACL, I’d say that would make sense.  The ACL allows the traffic from 10.0.0.14 (ICMP source on router4) to connect to 10.0.0.1, NOT 10.0.0.5.  A look at the interface counters confirms what we experienced…

So now that we’ve talked about the ‘reverse-path’ configuration, we need to talk about the ‘ip verify source’ configuration.  If you noticed, when you type in ‘ip verify unicast?’ on the interface sub configuration you get two options.  Source of reverse-path.  We just covered the reverse-path option, so let’s talk about the source option.

The truth of the matter is that they sort of do the same thing.  The reverse-path command syntax appears to be getting deprecated so we should really be using the ‘source’ option (plus it has more functionality).  Using the source syntax, we really have two main configuration options…

The first option is the ‘source reachable-via any’ syntax.  This is often referred to as the ‘loose’ mode of operation.  The ‘any’ configuration tells the router to pass the uRPF check if the prefix can be reached through ANY interface on the router.  Basically, if the prefix exists in the routing table, let it through. 

The second option is the ‘source reachable-via rx’ syntax.  This is often referred to as the ‘strict’ mode of operation.  This is exactly what we saw in the earlier examples.  This check to make sure that the router can access the prefix through the SAME interface that it received the traffic on. 

The ACL options work in the same manner in which they did in the above examples.  If initial uRPF check fails, check the ACL for an exception and then permit.  Let’s run through some examples of this quickly just to see the syntax…

This gives us the exact same behavior we saw with this last example…

Now let’s change it up a little and configure loose mode…

Here we see the pings working as expected…

It’s interesting to note here that router1 still treats loose mode as a ‘suppressed verification’…

Now let’s change things up a bit…

If we replace router1’s specific routes with a default route, let’s see what happens to our loose mode of operation…

Doesn’t work any more.  If you were to look at the IP interface on router1, you would see the uRPF is failing the checks and dropping the traffic.  But why is that?  Well, a 0’s route sort of makes a uRPF check invalid.  Thinking about it, that makes good sense.  If you only have 50 specific routes and then a 0’s route for the internet, there really isn’t a lot to check right?  Most routes will be internet facing and just work as expected.  To make this work, we need to change the uRPF configuration…

This configuration allows the uRPF check to consider the default route during it’s checks.  On the other hand, we could revert the configuration and just add a route like this…

Even though the 10’s route is effectively a summary, it still works…

The default route is the only one you need to watch out for. 

So there you have it, a quick look at uRPF check.  Hope this was helpful!

The post Unicast Reverse Path forwarding (uRPF) appeared first on Das Blinken Lichten.

Assuming that these switches were just ‘write erased’ (a new verb) and cabled in this manner, what would spanning tree look like?  Well, you should recall that spanning-tree likes configuration items that are lower.  Lower is better in spanning tree. 

Electing the root bridge – The switch with the lowest bridge ID becomes the root.  The bridge ID is a combination of the bridge priority and the bridge MAC address (Also the system ID extension, VLAN, but that’s the same per VLAN). 

Electing the root port – The root creates and sends hellos every 2 seconds.  Switches receive the hellos, update them with the appropriate information, and then forward them out all other ports.  The port that receives the hello with the lowest calculated cost to the root is the root port.

Electing the designated port – The switch that sends the hellos with the lowest advertised cost onto a segment.

So based on that information, and assuming that all of our ports are 10/100 Ethernet, we should be able to figure out what the topology is going to look like.  The cost of each interface should be 19 (Fast Ethernet cost) so let’s take a stab at what this topology will look like…

Picking the root here is a rather easy process.  All of the devices have the same priority so distro1 with the lowest MAC address wins the right to be the root.  Distro1 then begins forwarding hellos out of all of his ports.  The initial hellos will have a cost of 0.  Core will get the hello, add the cost of the ingress interface (19) to the hello and forward.  Distro2 will do the same thing.  Since both Core and Distro2 are receiving hellos with the same cost they need to fall back to the lowest bridge ID, followed by lowest port priority, followed by lowest forwarders port number.  In this case, the bridge ID of distro2 is lower than that of core so distro2 will win the designated router role for tat segment…

Taking a look at the spanning-tree output on the three switches we can see that we came to the correct conclusion…

Ok, so now we want to make the core the root bridge.  We can do this a couple of ways.  The main goal here is to make sure that the priority of the root bridge is the lowest…

Here we use the first method which is to ‘set’ the role of the bridge per VLAN.  In the first example, we set the bridge role to root primary.  This takes the current root bridge’s priority and subtracts 8192 from it.  If we use the secondary version of the command, it takes the current root bridge priority and subtracts 4096 from it.  In a stable topology (one that’s already configured) this would work out just fine.  However, if you set the primary on one switch, it’s just working off of the current root’s priority.  Let me show you what I mean…

Here I set the distro2 switch to be the vlan 1 root primary.  After things converge, I see that it is in fact the root of the spanning tree for vlan 1.  Now let’s go onto the core switch and manually change the priority…

As you can see, the core switch becomes the root.  The ‘spanning-tree vlan <vlan> root <primary|secondary>’ command only works of the existing settings.  That is, it’s a sort of macro that actually does the math and converts the ‘primary’ piece of the command to a hard number it puts in the config.  This is why I prefer actually setting the priority to using these commands.

Ok, so now we have the topology in place that I actually wanted to use in this post (took me a while to get there huh?).

Now let’s take a look at the spanning tree protection mechanisms that I wanted to talk about…

Root Guard
Root guard examines BPDUs that are heard through a particular interface and checks to make sure that they aren’t lower than the switches BPDU.  If it does hear a superior BPDU, the switch will put the port into a ‘root inconsistent’ state which prevents the port from passing traffic.  This prevents an unwanted port from becoming the root port on a switch.  If the condition clears, the superior BPDUs stop coming, the port is returned to it’s normal state.  As far as I can tell, the current recommendation is to enable this on access ports. 

It’s important to note here that it has to hear a BPDU that’s superior to the local switches BPDU.  NOT that of the roots.  For instance, if you enabled it on distro2’s port to the core switch that interface would go into the root inconsistent state.

Let’s take a look at a quick example…

Here we enable it on a single port on disto1.  Then we plug in the ‘user’ switch on that same port…

Any guesses on what will happen?

Nothing.  Why?  The BPDU the user switch is sending is not superior to the local distro1 switch.  See, you have to make some assumptions here.  If distro1 is NOT the root, then it’s BPDU is lower than the roots.  So as long as the new switch is not higher than the BPDU of distro1 (non-root) then everything is fine. 

So now let’s see what happens when we change the priority on the user switch to 0…

Instantly, the port on distro1 goes into root inconsistent.  We can see that in a couple of different outputs…

And when the priority changes back to normal, the port condition automatically restores to the normal forwarding state after going through the normal 802.1d port process…

BPDU Guard
BPDU guard is similar to root guard, but it’s more straight to the point.  If you have BPDU guard enabled on a switch, and you hear a BPDU, err-disable the port.  This condition can only be reversed by shutting and no-shutting the port to recover the err-disabled state.  The configuration is pretty straight forward…

Now if we plug the user switch back into that same port, we can see the action taken immediately…

So if you hear a BPDU, shutdown the port.  We can see this in a couple of different outputs…

BPDU Filter
Like the command suggests, BPDU filter prevents the port that the filter is configured on from sending BPDUs as well as disregards BPDUs that are coming into the port.  The configuration is pretty straight forward…

If we do the same test (plugging the user switch in distro1) we can see the results on each switch…

Dsitro1 puts the fa1/0/3 interface into the forwarding state after going through the normal STP port loading process..

And as you can see above, the user switch didn’t receive any BPDUs so it assume that it’s the root of it’s own STP domain. 

BPDU filter and guard in conjunction with portfast
I’m assuming that we all know what portfast is at this point.  But to summarize, it puts a interface into spanning-tree forwarding mode immediately.  Portfast can be enabled in two distinct ways.  The first is globally, and the second is by specific interface.  The key piece to understand is that they act differently based on the configuration. 

Global portfast puts access ports into the portfast state UNLESS they hear a BPDU.  If the port hears a BPDU, the port comes out of the portfast and goes through the normal listening, learning, forwarding spanning tree port process.  Interface portfast puts the port into an unconditional portfast mode.  BPDU or no BPDU, the port will always remain in portfast.

We can see the two different options in action below…

Above you can see what occurs when it’s configured globally.  The instant the port comes up and begins sending frames (BPDUs) the port loses it’s portfast status.  Now if we configure it on the interface…

We can see that despite receiving BPDUs, the port keeps it’s portfast status.  I bring this up because you can also configure the BPDU filter and guard functions globally on a switch.  These can be done via the following commands…

Note that these functions rely on portfast since it’s part of their configuration.  Keep this (any how portfast acts when it receives BPDUs) in mind when configuring the features.  For a deep dive on how these can interact check out Marko’s blog post on it here…

http://blog.ipexpert.com/2010/12/06/bpdu-filter-and-bpdu-guard/

Loop Guard
Loop guard is usually talked about in conjunction with UDLD.  The base premise of loop guard is that it prevents a port from transitioning from a blocking state to a forwarding state.  If you ran into a scenario where you had a link that failed in one direction.  The switch on the other end would no longer receive BPDUs and would believe that it should transition into forwarding mode.  This would cause a loop in the network.  If loop guard was turned on, instead of transitioning the port to forwarding, it would put the port in loop-inconsistent state.

The post Spanning Tree Protection review appeared first on Das Blinken Lichten.