Tag Archives: Cisco

ASA 8.4(2) under Ubuntu 12.04

I have managed to get the QEMU version of ASA running inside Ubuntu 12.04. Previously I have installed this on Windows and OSX. The trifecta will be complete with this post with the ASA running inside Ubuntu. Similar to the OSX post, the linux install has some subtle differences.

A working ASA 8.4 image
Ubuntu 12.04 – I am sure others may work.
GNS3-0.8.4-RC3-src.tar.bz2
QEMU-0.14.1-GNS3-Ubuntu-Linux64.tgz

Download and install GNS3 from Sourceforge. This is the latest version from May. It will update the look, feel, and importantly some behind the scenes features. This is rather straight forward.Next it is time to download the modified QEMU 14.0. Install this self extracting QEMU instance. It is pre-compiled and works with Ubuntu 12.04 64-bit LTS. It has been patched to support JUNOS devices too.

sudo ./Qinstall
Making Directrories - if directories exist you may see errors,
which can safely be ignored.
Please supply elevated credentials.
mkdir: cannot create directory `/usr/local/': File exists
mkdir: cannot create directory `/usr/local/bin/': File exists
mkdir: cannot create directory `/usr/local/share/': File exists
Making /usr/local/bin directory...
Making /usr/local/share directory...
Copying files to their proper locations...

All done. Have fun with your JunOS patched version of QEMU!

Alright. Now we need to open up and perform the same operations and steps inside GNS3 as we did in the MAC OSX post from earlier in the week. Now set the path to QEMU as the value below.

/usr/local/bin/qemu

Set your path to the Qemu-img to what is listed below.

/usr/local/bin/qemu-img

So now you have directed GNS3 to the QEMU install you extracted previously, now test. Your results should look like they do below.

Test and you should get the delicious green text of success as shown above. Now we need to set the ASA up under the ASA tab like the OSX post.

Now jump over to the ASA tab. This version of GNS3 has better support for QEMU instances. It actually pre populates fields. From the first drop down menu, Preconfiguration, ensure ASA 8.4(2) is selected. I set my RAM to 1024. Note QEMU options and Kernel command line options are filled. Unlike previously where you had to define them, GNS3 now does this for you. You need to select e1000 as the interface type in Ubuntu.

So fairly straight forward there. Now just drag an ASA from the side onto your topology and hit the play button. Console into your device and it is happy days. Yes, I did not set up my ASA properly and attempted to ping an interface without a route or security zone.

Voila. Now click save and close the preferences pane. Select from the side tab of devices, Security Devices, and drag onto your canvas an ASA firewall. Click the play button and watch it start-up. You will have two QEMU windows open. These may appear as not responding but whilst they are open, your ASA runs. If you do close them the ASA will disable itself and turn off so do not do this. Connect to them all via console (left of the play button) and enjoy the study.

I hope you have enjoyed this post and can apply what is demonstrated.

ASA 8.4(2) under OSX 10.8

2 Replies

One of my most popular blogs on Cisco Inferno is the ability to install and run an ASA firewall by Cisco on GNS3. Since then I have shifted to a Macbook Pro and want to run everything in OSX. I have been using GNS3 inside a Windows VM for a while but that is a waste of resource and more. I have yearned for lack of a better word for a way to run everything natively in OSX. Today is the day I share with you how to do this. The requirements are as follows.

A working ASA 8.4 image – (extracted as per previous ASA post)
OSX 10.8 – (I’ve tested this but 10.7 may work)
QEMU 11.0
GNS3 0.8.4RC2

Download and install GNS3 from Sourceforge. This is the latest version from May. It will update the look, feel, and importantly some behind the scenes features. This is rather straight forward.
Next it is time to download the modified QEMU 11.0. Install this self extracting QEMU instance. It is pre-compiled and works with OSX 10.8. It has been patched to support JUNOS devices too.

Now set the path to QEMU as the value below.

/usr/local/bin/QEMU-system-i386

Set your path to the Qemu-img to what is listed below.

/usr/local/bin/qemu-img

So now you have directed GNS3 to the QEMU install you extracted previously, now test. Your results should look like they do below.

Now time to select your ASA images.

Initrd

/Users/pandom_/Documents/GNS3/Images/asa842-initrd.gz

ASA Kernel

/Users/pandom_/Documents/GNS3/Images/asa842-vmlinuz

Voila. Now click save and close the preferences pane. Select from the side tab of devices, Security Devices, and drag onto your canvas an ASA firewall. Click the play button and watch it start up. You will have two QEMU windows open. These may appear as not responding but whilst they are open, your ASA runs. If you do close them the ASA will disable itself and turn off so do not do this

Here it is. My final topology. Connect to them all via console (left of the play button) and enjoy the study.

Major network RIP

Leave a reply

As I march onwards to the CCIE written the need is apparent that you must understand every trick and caveat of a routing protocol. I have been reading up and working on RIP this weekend and amongst the funny situations that have cropped up initially this one had me stumped.

The little topology focuses on R1 and R2. I have applied the following configurations.

 R1
interface Loopback0
 ip address 10.0.0.1 255.255.255.0
 !
 interface Loopback2
 ip address 10.0.1.1 255.255.255.0
 !
 interface FastEthernet0/0
 ip address 50.0.0.1 255.255.255.0
 duplex auto
 speed auto
router rip
 version 2
 network 10.0.0.0
 network 50.0.0.0
R2
interface FastEthernet0/0
 ip address 50.0.0.2 255.255.255.0
 duplex auto
 speed auto
router rip
 version 2
 network 50.0.0.0

Your output from R2′s routing table should look like this.

R2#sh ip route rip
 R 10.0.0.0/8 [120/1] via 50.0.0.1, 00:00:15, FastEthernet0/0

Due to the nature of auto-summary and it being on by default, as R1 advertising a RIP update to R2 it performs summarisation to the class-full boundary. This means our networks we configured, 10.0.0.0 and 10.0.1.0, albeit they have a /24 mask, they are being represented by the 10.0.0/8 route. To confim we shall check the debugs.

R1(config-router)#
*Mar 1 00:55:54.007: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (50.0.0.1)
*Mar 1 00:55:54.007: RIP: build update entries
*Mar 1 00:55:54.007: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:55:58.707: RIP: sending v2 update to 224.0.0.9 via Loopback2 (10.0.1.1)
*Mar 1 00:55:58.707: RIP: build update entries
*Mar 1 00:55:58.707: 50.0.0.0/8 via 0.0.0.0, metric 1, tag 0

Note here the update entries sending 50.0.0.0/8 and 10.0.0.0/8. We can deduce that auto-summary is occurring. Checking R2′s debug we can see that 10.0.0.0/8 is being received as advertised.

R2(config-router)#
 *Mar 1 00:56:51.627: RIP: received v2 update from 50.0.0.1 on FastEthernet0/0
 *Mar 1 00:56:51.631: 10.0.0.0/8 via 0.0.0.0 in 1 hops

We can also confirm what exactly is being seen with show ip rip database command.

R1#sh ip rip data
10.0.0.0/8    auto-summary
10.0.0.0/24    directly connected, Loopback0
10.0.1.0/24    directly connected, Loopback2
50.0.0.0/8    auto-summary
50.0.0.0/24    directly connected, FastEthernet0/0

R2#sh ip rip data
10.0.0.0/8    auto-summary
10.0.0.0/8
    [1] via 50.0.0.1, 00:00:18, FastEthernet0/0
50.0.0.0/8    auto-summary
50.0.0.0/24    directly connected, FastEthernet0/0

Note we see auto-summary entries next to 10.0.0.0/8 and 50.0.0.0/8 even though we did initially specify them with the individual network commands. There are /24′s in this table but remember this is due to being directly connected. They do not appear on their peer of R2.

What is a major network? A major network heralds back to the days of classes. The original use of RIPv1 was that it was designed to summarize at the enterprise edge to represent an entire business or network. A major network follows the original Class A, B, C network structure. Looking at the 4 most significant bits of the network portion you can see this in better detail.

Class A = 0000
Default mask = 255.0.0.0
Class B = 1000
Default mask = 255.255.0.0
Class C = 1100
Default mask = 255.255.255.0

What does that mean to you? Well a Class A range is 0.0.0.0 to 126.255.255.255. Combined with a default class-full mask of 255.0.0.0 this means that if there is a change in the first octet, you are crossing a major boundary. If anything is changed in the second, third, or fourth octet, you are residing in the major network of the first octet. This is still represented by a /8.

This scales the same way for Class B and Class C. A class B address residing between 128.0.0.0 and 191.255.255.255 with a subnet mask of 255.255.255.0 would change in the first two octets would indicate a major network crossing. A Class C address, residing between 192.0.0.0 to 223.255.255.255 would make any change to the the first three octets a change to the major network boundary.

If a different major network is running between the two devices then it is advertised back to the class full boundary. In the example of demonstrated above you can see that 50.0.0.0 connects between the two devices. The major networks are 10 and 50. When R1 sends the advertisements out they are summarized to the class full boundary.

How does one keep auto-summary one whilst advertising routes per our network statements? If the interconnect between R1 and R2 was in the same major network then it is treated differently. Lets apply 10.0.2.0 to the interconnect, replacing 50.0.0.0. Advertise them with RIP too.

R1
interface FastEthernet0/0
 ip address 10.0.2.1 255.255.255.0
 duplex auto
 speed auto
router rip
 version 2
 network 10.0.0.0
 network 10.0.1.0
 network 10.0.2.0
 R2
interface FastEthernet0/0
 ip address 10.0.2.2 255.255.255.0
 duplex auto
 speed auto
router rip
 version 2
 network 10.0.2.0

Now check the ip routing table. Look at the different from before. Where we had the entire 10.0.0.0 network summarised by a /8.

R2#sh ip route | beg Gateway
 Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
 C 10.0.2.0 is directly connected, FastEthernet0/0
 R 10.0.0.0 [120/1] via 10.0.2.1, 00:00:14, FastEthernet0/0
 R 10.0.1.0 [120/1] via 10.0.2.1, 00:00:14, FastEthernet0/0

Here you can see that now we have changed the major network on the interconnect to reside in the overall class-full network range we have a much different result. Our RIP routes on R2 show two networks, 10.0.0.0 and 10.0.1.0. Lets see how the updates are different this time.

R1#
 *Mar 1 00:52:50.619: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.2.1)
 *Mar 1 00:52:50.619: RIP: build update entries
 *Mar 1 00:52:50.623: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
 *Mar 1 00:52:50.623: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
R2#
 *Mar 1 00:53:58.383: RIP: received v2 update from 10.0.2.1 on FastEthernet0/0
 *Mar 1 00:53:58.387: 10.0.0.0/24 via 0.0.0.0 in 1 hops
 *Mar 1 00:53:58.387: 10.0.1.0/24 via 0.0.0.0 in 1 hops

Look at that, we can see two new networks in the updates being sent and received based upon these outputs.

So now we can see that if an interconnect between peers does not reside on the same major boundary then summarisation to the class-full edge will occur. What happens where we turn auto summary off and repeat what we did before? First with the 50.0.0.0 network then the 10.0.2.0 network.

With the 50.0.0.0 network as the interconnect I disabled auto-summary on both devices.

R1(config)#router rip
R1(config-router)#no auto
R2(config)#router rip
R2(config-router)#no auto

Time to check our outputs and debugs. First the output of the routing table

R2#sh ip route rip 
 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
R 10.0.0.0/24 [120/1] via 50.0.0.1, 00:00:20, FastEthernet0/0
R 10.0.0.0/8 [120/1] via 50.0.0.1, 00:01:16, FastEthernet0/0
R 10.0.1.0/24 [120/1] via 50.0.0.1, 00:00:20, FastEthernet0/0

Ah yes. With auto-summary off note that the correct networks are advertised including their subnet mask. No automatic summary replaces all the networks so we will get the 10.0.0.0/8 (due to crossing the major network boundary) plus the two more specific entries denoted by the /24 networks.

R2#show ip rip data
10.0.0.0/8 auto-summary
10.0.0.0/8
 [1] via 50.0.0.1, 00:01:36, FastEthernet0/0
10.0.0.0/24
 [1] via 50.0.0.1, 00:00:10, FastEthernet0/0
10.0.1.0/24
 [1] via 50.0.0.1, 00:00:10, FastEthernet0/0
50.0.0.0/8 auto-summary
50.0.0.0/24 directly connected, FastEthernet0/0

Showing our RIP data we get the expected output. Now lets change back our interconnect to 10.0.2.0 network and see the difference now that we have auto-summary disabled.

R2#sh ip rip data
10.0.0.0/8 auto-summary
10.0.0.0/24
 [1] via 10.0.2.1, 00:00:03, FastEthernet0/0
10.0.1.0/24
 [1] via 10.0.2.1, 00:00:03, FastEthernet0/0
10.0.2.0/24 directly connected, FastEthernet0/0

Good. Look at that. We can see the two /24′s being advertised from 10.0.2.1 (R1′s interconnect) which R2 reaches via FastEthernet0/0.

R2#
*Mar 1 04:35:24.162: RIP: received v2 update from 10.0.2.1 on FastEthernet0/0
*Mar 1 04:35:24.162: 10.0.0.0/24 via 0.0.0.0 in 1 hops
*Mar 1 04:35:24.162: 10.0.1.0/24 via 0.0.0.0 in 1 hops

The inbound update packet lists our two networks including their mask! Huzzah! This means we have the correct updates from R1 and they are there specific networks. No entire /8 being thrown into our routing table. Time to issue a show route.

R2#sh ip route | beg Gate
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
C 10.0.2.0 is directly connected, FastEthernet0/0
R 10.0.0.0 [120/1] via 10.0.2.1, 00:00:12, FastEthernet0/0
R 10.0.1.0 [120/1] via 10.0.2.1, 00:00:12, FastEthernet0/0

There we go. Nice and neat. A clean and expected routing table.

So there we go. It goes to show that even RIP, the routing protocol that stands in the shade of its bigger brothers has some curve balls up its sleeves. There are plenty more blogs like this to come. I hope you have enjoyed this and continue with me as I did deeper into the CCIE RS.

Dale dug a hole, Anthony made a script

8 Replies

You may think my title is odd. Well there is an explanation. There is an Australian classic movie called ‘The Castle’. It is about an average Australian family who just make do and appreciate their family and lot in life. The lead character, Darryl Kerrigan, is proud of his home and will do anything to defend and protect it. In a scene where the family talks about their day, one of the sons responds to Darryl’s question with “Dale dug a hole”. Darryl is genuinely proud of him even though us the view laugh at the delivery and genuine sincerity Darryl shows. Well, I made a script and this is how I felt. Something quite meaningless but I felt a sense of achievement and accomplishment.

I have had some issues recently with configurations changing without authorization. We have a AAA service happening but extracting the data isn’t nice. I thought that I would start by pulling down configurations and comparing them. This could be done to show differences in proposed configuration to running configurations and make sure scope creep is kept under control.

wget --user=aburke --password=abc123 --no-check-certificate https://192.168.30.4/admin/exec/show%20running-config%20asdm/show%20running-config#

The above file can be copied and pasted around. This works well but is a manual process.

wget-2

As you can see you are able to connect on 443. As this device is in my lab it is okay that my password is simple – abc123 – though I recommend guarding your scripts as they will contain vital information.

wget-3

The script outputs the configuration to where the script is run from. In this case, for me it is my user folder. Now it is time to automate this. I am going to add this scripts execution to CentOS crontab file. It will allow automatic execution on a regular basis. So I saved my above script as wget-ASA-config.sh. I used this chart as reference for timing to get my 0200 hours for Sunday.

*    *    *    *    *  command to be executed
┬    ┬    ┬    ┬    ┬
│    │    │    │    │
│    │    │    │    │
│    │    │    │    └───── day of week (0 - 7) (0 or 7 are Sunday, or use names)
│    │    │    └────────── month (1 - 12)
│    │    └─────────────── day of month (1 - 31)
│    └──────────────────── hour (0 - 23)
└───────────────────────── min (0 - 59)

I came up with the following for my crontab entry.

00 2 * * 0 root wget-ASA-config.sh echo "ASA config wget shell run at 0200 every Sunday"

After saving this to the crontab file this will execute when system time reaches the time specified. I currently use the compare plugin for Notepad ++ on my corporate desktop. At home I could use Textwrangler or Textmate on OSX.

Here I have two text files open. Each one is a configuration from each day. The blue column on the right shows where there is a difference in the document. This line is shows where in the document. Note that it is easy to differentiate if something is changed by the natural color scheme. Red subtraction shows something is missing, yellow exclamation mark indicates the line is altered, and a green plus shows addition.

Now my script is simple and rough. I need to alter it to append the system date and if possible put it in a better directory that my home file. That will come as I fiddle around. My thoughts of being able to generate an email when a change is detected via a script opposed to me looking should be feasible too.

I was rather chuffed when I figured that out and thought someone out there might be interested.

NX-OS and Cisco Nexus Switching

1 Reply

The data center is ever evolving and in the heart of many is the Cisco Nexus platform. This device series has many different opinions based on who you speak to. Birthed out of a secret project, the Nexus family hit the market with a modular OS, and focused on fast DC switching.

This book reviewed will be the subject of this post. Ron Fuller gave me an electronic copy of this book via Ciscopress.com. This was a gesture of good faith from an industry professional to another. No expectation of a blog was discussed let alone anything in return for this.

About the Book

Ron Fuller, Technical marketing engineer for the Nexus 7000, has gathered with fellow authors once again. Their unrivaled knowledge has been pooled and they have delivered the second edition of the ever popular NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures.

Released by Cisco Press on the 18th of March this book is a 847 page whopper. Delivered in a variety of formats it will appeal to those with a physical or digital need. Cisco Press online allow for delivery in pdf, mobi, and epub formats. PDF is great for reading on my mac book whilst epub suits my train ride with my Nexus 7. The watermark is subtle with the note “From the Library of Anthony Burke” on each page down in the right hand corner. I like this minimal amount of watermark as I find some can be painful. A bonus too is that it is not a secure PDF or locked with LockLizard or something like that.

Book overview

The style of this book alternates between a technical recital and then an example. The tone used by the authors change a little between sections. Albeit I do not know who wrote each section you can determine a different author here and there. This is not a bad thing but I definitely preferred one sections writing style to another.

The style of the book plays well to my learning habits. I like the technical nature upfront then some configuration examples. This allows you to playt along at home. After the basics have been covered alternates and add ons are introduced. If you follow the flow of the book you can start out with nothing and end up with a very functional DC skill set. Each chapter builds on each one before it but if you have had exposure you can pick up any topic at any place.

The chapters I found most interesting we definitely OTV and LISP. The overlays were discussed in detail with references to external resources and strong implementation knowledge. I felt like I could go an apply an overlay with confidence. The LISP chapter also brought to the forefront the technology behind it and also how it is achieved. The use cases came very apparent after a re-read.

With virtualisation rife throughout DC’s world-wide, network virtualisation is a hot word of CEO’s lips. This book focuses a lot on how to unlock the Nexus platform’s ability to accommodate multi-tenant data centers and hosted offerings.

The best addition was a case study at the end. This focused on an existing environment moving to the nexus platform. It outlined goals, the design, the migration plan, example outage windows and what occurred within each, and ended with ongoing windows and a summary. If you weren’t a customer before hand, they definitely demonstrated the power that NX-OS can bring to your DC.

Rating

Overall this book follows up on the precedence the first set. A technically accurate book with clever and relevant examples serves as a good desk side reference for any DC engineer. I give this book a 8.5/10.

Thanks Ron, David, and Matthew.

Who needs more than 4094 VLANs?

Leave a reply

First world DC problems

Cloud computing has thrust multi-tenant DC’s forward in their advancements. The elasticity required for rapid deployment has pushed the bounds of many fields including storage, virtualisation, server architectures, and orchestration. As our environments onboard different customers in a multi tenant data centre, path isolation, and Equal Cost Multi Path (ECMP) becomes a requirement.

Path isolation can be performed at Layer 2 and Layer 3. Traditional Layer 2 isolation has been performed by putting Customer A into VLAN 10, Customer B into VLAN 11. Layer 3 isolation can per applied through VRFs, overlays, and other technologies.

If a cloud provider services a bulk of customers that all require path isolation – and you expect this to be the case – then VLAN allocation will dry up fast. A DC may want to offer ECMP to a customer providing them with an interconnection with the use of IP for interconnection. They will also want to maintain and preserve the Layer 2 model for inter-VM communications.

Encapsulated overlay

A solution exists. It has been put forth by our pals at Cisco and VMware is VXLAN. Entitled VXLAN: A Framework for Overlaying Virtualised Layer 2 Networks over Layer 3 Networks.

VXLAN is an overlay network that helps alleviate the problems of the cloud network environment. By addressing L2 and L3 DC network challenges of ever moving virtual machines, administrators can over come constraints of traditional networking.

You can like VXLAN to Layer 2 over Layer 3. Each different overlay is referred to as a VXLAN segment. VXLAN segments differs from a VLAN segment in that it uses a 12 bit – opposed to 12 bit – segment ID. This allows 16,000,000 VXLAN segments to be assigned. A vast improvement over 4096. The VXLAN Network Identifier (VNI) represents the segment.

The VNI wraps itself around the existing MAC frame that came from the existing VM. It protects the existing frame this way, allowing new information to be written and interpreted by network devices along a given path.

VXLAN is , due to the outer wrapper, or envelope, essentially a tunnelling mechanism. With L2 wrapped around the traditional L3 and L2 packet. VLAN Termination end points (VTEP) are located in hypervisors on servers. These VTEPs strip VNI information before the hypervisor passes a VXLAN frame to the server. The guest never sees it. Hardware termination of a VTEP inside a switch is also possible, though it requires certain chipsets such as a Trident II. The Trident II supports VXLAN and VTEP termination.

My mind wanders to two hosts that are separated by a layer 3 segment. They could even be in the same layer 2 segment. They could be in different racks in different parts of a data centre. VXLAN would then be overlaid upon the aforementioned networks.

Half a dozen VNI’s could be in each hypervisor of each host. Between each host in separated L3 subnets, a logical tunnel is formed between VTEPs. Guests on the host seeking to communicate to other hosts with the VNI can due to the overlay. The host believes it is in an adjacent network.

A switch acting as a VTEP gateway could host servers behind it and do the termination on the switch itself. This would allow a different topology to be formed. This requires support in the hardware as well as software. Over time this will be default in silicon.

My thoughts

The notion is how MPLS label switches across a WAN core and strips labels accordingly. Well, at least it is in my head. Moving forward I believe this overlay may find more traction as it can be terminated in a hypervisor. Upgrade your cluster and you’ll have support. With announcement of NSX, it is time to understand VXLAN overlays.

i(OS)Message

Leave a reply

Ever needed to deploy a device where multiple engineers are working in tandem. This could possibly be from different sites or someone peer reviewing configurations with you. I have. I have also not be able to access a phone or been somewhere very noisy. You have the ability to chat across vty lines on IOS. This isn’t new and has been around since before I was born but Today I will show you how you can add this tool to your skill set.

Let see what line the other engineer is using. We do have our name stating who we are but in case you forget there is out little asterisk to remind us.

4500-lab-01#sh user
    Line       User       Host(s)              Idle       Location
*  1 vty 0     aburke     idle                 00:00:00 192.168.22.50
   2 vty 1     sburns     idle                 00:00:19 192.168.22.57

  Interface      User        Mode                     Idle     Peer Address

Now I have noticed an error on interface T7/3 with an error count. I can’t call sburns nor do I have internet access. Time to let him know what I want him look to to confirm my findings.

4500-lab-01#send vty 1 
Enter message, end with CTRL/Z; abort with CTRL/C:
Have a look at the interface T7/3's error count. Do you think it is a bit high? 
Lets reset the counters and check.
^Z
Send message? [confirm]
4500-lab-01#

On sburns screen we can see what appears in the console.

4500-lab-01#

***
***
*** Message from tty2 to tty1:
***
Have a look at the interface T7/3's error count. Do you think it is a bit high? 
Lets reset the counters and check.

I have clearly and effectively communicated to my coworker the information I needed to get to him. Rather cool. It is just something you can use in your toolkit. This could also be perfect for those moments when you don’t want to deal with the person on the end of the phone.

Lateral considerations

1 Reply

I have been working on deploying some Nexus fabric over the last few months. The standard life cycle comes and passes and as I was sating my want to know about everything I was reading some interesting information. It is well-known the Nexus 2000 devices act as remote line cards for their older 5000 or 7000 brothers. Any layer 2 lookup or transaction is passed upwards to the master device before being forwarded on. This is a standard action you might say; I don’t think you expected this on neighbouring ports.

On neighbouring ports a normal switch such as a 3750 with a standard architecture would perform the lookup and forwarding decision on the switch and forward out another port on the device. With the distributed architecture of the Nexus family the brains of the platform reside in the 5000 or 7000. With the 2000 acting as ToR switch it must pass traffic up towards a 5000 or 7000 to perform lookup and forwarding decisions. This requires some thought. If you are placing a series of VMware hosts onto the access layer fabric some traffic considerations need to be made.

Same switch chatter can be bad on uplinks

In the example below a VMware device may have two hosts of different clusters. A guest on cluster A may communicate to a guest on cluster B. This would mean traffic would traverse up and down a single uplink port channel. From a design consideration your East West traffic needs to be taken into consideration. The traffic that is intraDC such as vMotion between cluster hosts, Database backups, storage vMotion or DRS.

Situational harmony

The above picture shows a bit more balance. Across two 5000′s traffic patterns can be balanced. This would be when VM load distribution is optimal. If an evacuation of a cluster host occurs or LUN abandoning is in progress such patterns need to be catered for. Sometimes you cannot always optimise but situations can arise where a sub optimal situation are for a short period of time.

Understanding the dependencies of your application architecture is paramount to a good East West traffic management. Ask good questions of your applications team. Speak to your storage team. iSCSI and FCoE users in particular. Teamwork is key here. The network is the fabric that binds us and we need to share it. Don’t be a jerk and accuse or belittle. Respect their application and they will respect your network. Just remember, vMotion/Storage vMotion/Unified vMotion respects no one and will use ALL THE BANDWIDTH!

Pins in the fabric

Leave a reply

The Nexus series of data center switches by Cisco allow for an extended fabric configuration. By utilising the notion of remote line cards, an engineer can deploy Nexus 2200 series switches as Top of Rack. These top of rack switches allow for data center access for servers. Nexus 5000 series (or 7000) for that matter act as the master. These are what the Nexus 2000 series pin back to.

With the mindset of remote line card now in your head let’s get on the job about pinning one. This exercise will show you how to pin a Nexus 2248TP to a Nexus 5548UP switch. The term FEX is used and is short for Fabric Extenders, referring to the Nexus 2200 series.

The above diagram shows you how we are going to pin our access layer devices to each switch. Below we will pin our device with the following configuration. I have two 10Gb Twinax cable links connected from Nexus 2248TP up to the 5548UP. I am going to single home each FEX to an upstream Nexus 5548. Aligning even-numbered FEX and odd-numbered FEX to their own upstream 5548 allows for rack redundancy in the situation of a failure. Servers has a choice to be connected to both FEX’s allowing diverse paths. The above deployment would suit three Racks worth of switches for fabric redundancy. You can dual home your FEX devices and Tony Mattke goes in depth about design considerations.

Ensure your Nexus 5000 device is powered on and the Nexus 2200 device is not before continuing.

LAB-N5548-1(config)# int e1/5-6
LAB-N5548-1(config-if-range)# channel-group 101
LAB-N5548-1(config-if-range)# int po101
LAB-N5548-1(config-if)# switchport mode fex
LAB-N5548-1(config-if)# fex ass 101
LAB-N5548-1(config-if)# exit

The commands are easy enough. Add ethernet 1/5 and 1/6 to channel-group 101. Under the interface of port-channel 101 the switchport mode is not access or trunk but something unique to the NX-OS. Fex. Fex ports tell NXOS to expect a remote line card on this port. Then associate and identify that FEX number 101. Ahh, I have a thing with consistency in my deployments. Port group 101, Fex 101…. You get the idea! So let us confirm what is happening now.

LAB-N5548-1# sh fex
  FEX         FEX           FEX                       FEX
Number    Description      State            Model            Serial
------------------------------------------------------------------------
---       --------             Connected     N2K-C2224TP-1GE   SSI163504DR

Okay so a downstream device is connected. This is good. The serial number matches up which is handy. Let us check the detailed output.

LAB-N5548-1# sh fex det
FEX: 101 Description: FEX0101   state: Image Download
  FEX version: 4.2(1)N2(1) [Switch version: 5.2(1)N1(1)]
  FEX Interim version: 4.2(1)N2(0.51)
  Switch Interim version: 5.2(1)N1(1)
  Module Sw Gen: 12594  [Switch Sw Gen: 21]
  post level: complete
 pinning-mode: static    Max-links: 1
  Fabric port for control traffic: Eth1/5
  FCoE Admin: false
  FCoE Oper: true
  FCoE FEX AA Configured: false
  Fabric interface state:
    Po101 - Interface Up. State: Active
    Eth1/5 - Interface Up. State: Active
    Eth1/6 - Interface Up. State: Active
Logs:
02/04/2009 02:58:28.251005: Module register received
02/04/2009 02:58:28.251699: Image Version Mismatch
02/04/2009 02:58:28.252053: Registration response sent
02/04/2009 02:58:28.252224: Requesting satellite to download image

Look at that. The FEX is downloading and installing a newer software from the Nexus 5000. I didn’t expect this to be running its own software by itself. Due to the nature of the Nexus 2000 requiring an upstream 5000 I naturally through it would be “boot from SAN” styled power on. Note that the 4.2 code is moving on up the parents 5.2. Upgrades! Time to grab a coffee whilst I wait.

LAB-N5548-1# sh fex det
FEX: 101 Description: THO-EST-FEX-P2-101 state: Online
FEX version: 5.2(1)N1(1) [Switch version: 5.2(1)N1(1)]
FEX Interim version: 5.2(1)N1(1)
Switch Interim version: 5.2(1)N1(1)
Extender Serial: SSI163504DR
Extender Model: N2K-C2224TP-1GE, Part No: 73-13373-01
Card Id: 132, Mac Addr: 88:75:56:c0:68:02, Num Macs: 64
Module Sw Gen: 12594 [Switch Sw Gen: 21]
post level: complete
pinning-mode: static Max-links: 1
Fabric port for control traffic: Eth1/5
FCoE Admin: false
FCoE Oper: true
FCoE FEX AA Configured: false
Fabric interface state:
Po101 - Interface Up. State: Active
Eth1/5 - Interface Up. State: Active
Eth1/6 - Interface Up. State: Active
Fex Port State Fabric Port
Eth101/1/1 Down Po101
Eth101/1/2 Down Po101
Eth101/1/3 Down Po101
Eth101/1/4 Down Po101
Eth101/1/5 Down Po101
<snip>
Logs:
02/04/2009 02:58:28.251005: Module register received
02/04/2009 02:58:28.251699: Image Version Mismatch
02/04/2009 02:58:28.252053: Registration response sent
02/04/2009 02:58:28.252224: Requesting satellite to download image
02/04/2009 03:07:32.676640: Image preload successful.
02/04/2009 03:07:33.816624: Deleting route to FEX
02/04/2009 03:07:33.825731: Module disconnected
02/04/2009 03:07:33.826383: Module Offline
02/04/2009 03:07:33.846159: Deleting route to FEX
02/04/2009 03:07:33.853588: Module disconnected
02/04/2009 03:07:33.854835: Offlining Module
02/04/2009 03:08:28.252593: Module timed out
02/04/2009 03:08:51.563834: Module register received
02/04/2009 03:08:51.565068: Registration response sent
02/04/2009 03:08:51.782832: Module Online Sequence
02/04/2009 03:08:56.416394: Module Online

LAB-N5548-1#

Note the state has change from Image Download to Online. This is noted also by the FEX log at the bottom. Looking also at the output the FEX has added interfaces with a slot aligned with the FEX number. I have cut some out for brevity but Eth 101/1/1-24 now exist! You can pin-up to 12 FEX’s to a Nexus 5000 series. You can appreciate the flexibility this gives opposed to chassis switches. It is important to take into consideration failure domains and what affects this on uplink bandwidth. This allow for great expansion, flexibility with different access layer mediums, and ease of management.

EIGRP to be part-open but why bother?

5 Replies

My first taste of networking came via the Cisco Learning Academy. I did my CCNA and the old school ROUTE, and it did a pretty good job of praising the joys of EIGRP. You learned EIGRP early on, and it was always made to sound superior. The skills tests and all the labs revolved around EIGRP. It seemed awesome at the time. OSPF was referred to like “that Uncle” that everyone has and is scared to have around their partner.

I came across an article earlier that stated EIGRP was to be made an open standard. Cisco finally must be getting a bit sweaty under the collar if they are doing this. They know most of their customer base uses OSPF. Juniper, their fiercest opponent, have proliferated OSPF users due to a high number of router sales. This has tipped the scales WELL in favor of OSPF.

Upon seeing the article title, I got excited. EIGRP would be open. A draft is released to the IETF, EIGRP becomes ratified, and some vendors may pick it up. Most arguments against EIGRP recommend avoiding it due to vendor lock-in. No one wants to be stuck with a proprietary protocol. This is compounded by the fact that financially viable, sound alternatives exist to Cisco these days. Back when EIGRP was the best thing since sliced bread, there wasn’t much competition. Like Cisco licensing, a big stumble occurred in the second paragraph.

What Cisco should have said in its announcement was that, “Cisco EIGRP is now an open standard,but…” The article goes on to list three things that irked me right away, and gave me the notion to rename their article.

Advanced features of EIGRP (namely stub areas) will not be released to the IETF.
Informational RFC allows Cisco to retain control of the EIGRP protocol.
EIGRP is still technically proprietary.

So, the advanced features of EIGRP are not being released – no stub areas, no way to control propagation or logically define areas. No DMVPN topologies that will scale. This is one of the primary reasons you would use EIGRP. In a past life I did a deployment, and I’ve labbed many since. It works and works well, but you can learn to rearchitect around it. Why do that? Because other vendors offer such a better price point that it is cheaper to migrate than pay to be locked in, a giant area to be sad about. Sure, you could run different processes and redistribute between but you shouldn’t have to just because Cisco wants to hold the keys.

Cisco’s best interests will always guide the EIGRP protocol. This could potentially lead to stifled innovation from the outside, as they have final say. On the one hand, they ask vendors to develop, but still tightly control the best features. I do understand protecting customers who’ve invested in it, but why bother with this?

Which really leads to number three. The best features are tightly controlled. That’s not really open source, now is it? I expected it to be rather open, but there are caveats. I have nothing against protecting interests, but wouldn’t you just not bother if you’re imposing these limitations? Has Cisco not learned from its previous endeavors – namely ISL and PAgP, but many more that others can point out – that proprietary means lock in? Lock in equals no-no. NO means NO.

Maybe I am being a bit too harsh. I have reached out to Donnie Savage with a hope to chat more about the draft. I believe my thoughts will remain much the same, but I’m always looking for another perspective. I appreciate Cisco giving this a go, this open standard thing with EIGRP. I could be missing something, but it seems this one, so far, is a misstep.

Juniper Networks JNCIS-ENT Exam Review

3 Replies

Today I sat the JNCIS-ENT exam. As my previous post let on, I didn’t pass the exam the first time. I was close but not close enough. I felt it was a fair exam and I am going break it down. I have used the template that Ethan Banks has used for review of his CCIE written attempt. I felt it gave great information.

Exam Quality

Liz Burns and the JNCP team has ensured that the exam delivered by Pearson Vue is of a top quality. I found that the font was easy to read which made for analysis of questions less stressful. Network Diagrams were of a high quality without errors. The only little issue I had were when example snippets of text were actually pictures and when enlarged they blurred a little. That is no worries but for someone like me who has kittens in an exam room, it made it a little stressful. Maybe in the popup box, text could appear opposed to a picture.

Exam Topic Coverage

The routing and switching topics covered in my opinion were of a high level. If comparing to Cisco Systems CCNA and ROUTE/SWITCH exams from the CCNP, I would say there would be a mix. I found the questions to cover each topic fairly though I seemed to have a lot on OSPF LSA types and where they’d appear, IS-IS, and BGP redistribution. I didn’t have to memorize many silly things like odd protocols and numbers. I enjoyed seeing some of the obscure ones as I already knew it from a recent trouble ticket! Cough IP type Cough

Exam Difficulty

This isn’t a walk in the park. Especially when you book the wrong exam. I went to book JNCIS-SEC and accidentally booked JNCIS-ENT. I manned up and accepted the challenge. Shame I missed it by 3 percent. Juniper specifics were my weak point – not enough exposure. If you are working on your Juniper skills you want more than just a fiddle at the command line. It requires labbing and reading and more labbing. I found that the questions were not your run of the mill “What port does BGP run on?” and the like. That being said, 1/3 of the questions were substantially easier than others.

I think this myriad of difficult, if consistently delivered will help alleviate brain dumpers. As long as no one gets an exam of all simple questions.

Exam Preparation

I do have a background in networking and my workplace is 100 percent Cisco Systems so I rely on what I already know. I own an SRX110H-VA and it is my device in where I work with. I used the FastTrack guides on the JNCP page for this course. I did some light RFC reading. I felt, although I didn’t pass, was enough to cover the topics asked. On my next attempt I am actually going to print the JNCIS workbooks for ENT and mark and draw on them a bit more.

Conclusion

Juniper really have taken the best feedback of all exam paths (Microsoft, Cisco) and produced a sound environment to test knowledge. It actually felt like a test which was a proving ground of knowledge. My previous pass on the JNCIA-JUNOS was a totally different experience. I’d like to take this opportunity to thank Juniper for delivering easily accessible material for their courses. This provides the answer to any excuse a Cisco-only engineer has to taking up Juniper studies.

~~I will meet JNCIS-ENT before February 4th again. This time, I will take my certificate.~~

EDIT
Today, January 21, I sat the exam again. I did some more revision on the exam blueprint topics and I came out with a pass! 94%! My views on the exam are the same as before!

Guard the edge with Junos

2 Replies

Just a quick one today. I had planned to take the JNCIS-Security this month but accidentally booked JNCIS-Enterprise. Not to worry in the slightest. The same great content will be served up, just with a focus on routing and switching. Remember back to an earlier post where I made a virtual lab? Well now it is going to come in very handy for Protocols. Before we get there it is time to brush up on some switching differences.

Now BPDU guard is a feature that is a must. Spanning-tree hasn’t died yet and you just never know when someone might do something silly like, oh, plug an older switch into the network. This innocent act could drop your network, suboptimally optimally alter your L2 topology, or get a managerial foot knee-deep somewhere painful. Let’s protect this with our Junos based switch/SRX. Let us change firstly the spanning-tree mode from the default of STP to RSTP.

set protocols rstp
commit and-quit comment "Change STP mode"

Just confirming my edge port. This port, along with fe-0/0/2 and 3 are access ports. I will never plan on plugging a switch into this device and expect only end users.

root@SRX110> show spanning-tree interface fe-0/0/1    

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
fe-0/0/1.0     128:514      128:514  32768.b0a86e66e208    200000  FWD    DESG

Okay. Now we confirm that Spanning-tree is running and my port is forwarding let us add some RSTP enhancements. I want to enable these ports to transition to forwarding immediately, avoiding listening and learning, and to shut down if a BPDU is received. On IOS, the prior is known as Portfast. I do not want to apply a global configuration in this example.

set protocols rstp interface fe-0/0/1.0 edge  
set protocols rstp interface fe-0/0/2.0 edge 
set protocols rstp interface fe-0/0/3.0 edge  
set ethernet-switching-options bpdu-block interface fe-0/0/1.0
set ethernet-switching-options bpdu-block interface fe-0/0/2.0
set ethernet-switching-options bpdu-block interface fe-0/0/3.0

RSTP edge ports allow an automatic transition to forwarding and bpdu-block will violate and shutdown a port if a BPDU is detected. A quick verification of what we configured is important.

root@SRX110> show ethernet-switching interfaces fe-0/0/1.0    
Interface    State  VLAN members        Tag   Tagging  Blocking 
fe-0/0/1.0   up     vlan-trust          3     untagged unblocked

root@SRX110> show spanning-tree interface fe-0/0/1 detail

Spanning tree interface parameters for instance 0

Interface name : fe-0/0/1.0
Port identifier : 128.514
Designated port ID : 128.514
Port cost : 200000
Port state : Forwarding
Designated bridge ID : 32768.b0:a8:6e:66:e2:08
Port role : Designated
Link type : Pt-Pt/EDGE
Boundary port : NA
Edge delay while expiry count : 10
Rcvd info while expiry count : 0

Spanning-tree commands show To confirm EDGE status you can see under the link type that EDGE is listed. Now if I plug a switch with a lower priority what happens?

root@SRX110> show ethernet-switching interfaces fe-0/0/1.0    
Interface    State  VLAN members        Tag   Tagging  Blocking 
fe-0/0/1.0   down   vlan-trust          3     untagged Disabled by bpdu-control

Network safe for now. Time to hunt down the culprit. Now we have to recover the port for further use. Use the following command to recover the port

clear ethernet-switching bpdu-error

It would be a pain to recover ports if you have this sort of issue occurring frequently. You can use JUNOS’ version of the IOS command err-disable recovery.

root@SRX110# set ethernet-switching-options bpdu-block disable-timeout ?
Possible completions:
      Disable timeout for BPDU Protect (10..3600 seconds)

set ethernet-switching-options bpdu-block disable-timeout 60

Good feature. Remember that shut and no shut won’t fix the port that is violated. It must be cleared of its error. I prefer automatic but you may not need the auto-clear feature. It has saved me many times in the past and now you know how to configure it for Junos. Thanks for reading!

Nexus “ah-ha” moment part 1

1 Reply

I have been using the Nexus platform for a year now. I always find I get “ah-ha” moments due to the fact most of the time I am hiding in IOS. Here is a little one regarding showing interfaces. I found this early on to be painful thinking “Where are my FEX’s”.

Showing L3 Interfaces

NX-OS – N5k

LAB-MEL-SVRSW-P1-2# sh ip int br
IP Interface Status for VRF "default"(1)
Interface IP Address Interface Status
Vlan1000 10.10.100.10 protocol-up/link-up/admin-up

IOS – C4507e SUP6L-E

LAB-MEL-CORESW-01#sh ip int br
TenGigabitEthernet7/1  unassigned      YES unset  up                    up      
TenGigabitEthernet7/2  unassigned      YES unset  up                    up      
TenGigabitEthernet7/3  unassigned      YES unset  administratively down down    
TenGigabitEthernet7/4  unassigned      YES unset  administratively down down    
TenGigabitEthernet7/5  unassigned      YES unset  administratively down down    
TenGigabitEthernet7/6  unassigned      YES unset  administratively down down

Okay this is good. We can see our interfaces. On the Nexus 5000 we don’t see our FEX. I know I have a lot plugged in. What command do I need to see over 120 ports? Oh and by the way, on IOS, You cannot issue the same command.

IOS – C4507e SUP6L-E

LAB-MEL-CORESW-01#sh interface br
                               ^
% Invalid input detected at '^' marker.

NX-OS – N5k

LAB-MEL-SVRSW-P1-2# sh interface br

--------------------------------------------------------------------------------
Ethernet      VLAN   Type Mode   Status  Reason                   Speed     Port
Interface                                                                   Ch #
--------------------------------------------------------------------------------
Eth1/1        1000   eth  trunk  up      none                        10G(D) 11
Eth1/2        1000   eth  trunk  up      none                        10G(D) 12
Eth1/3        1000   eth  trunk  up      none                        10G(D) 64
Eth1/4        1000   eth  trunk  up      none                        10G(D) 64
Eth1/5        1      eth  access down    SFP not inserted            10G(D) --
Eth1/6        1      eth  access down    SFP not inserted            10G(D) --
Eth1/7        1      eth  access down    SFP not inserted            10G(D) --
Eth1/8        1      eth  access down    SFP not inserted            10G(D) --
Eth1/9        1      eth  fabric up      none                        10G(D) 105
Eth1/10       1      eth  fabric up      none                        10G(D) 105
Eth1/11       1      eth  fabric up      none                        10G(D) 107
Eth1/12       1      eth  fabric up      none                        10G(D) 107
Eth1/13       1      eth  fabric up      none                        10G(D) 111
Eth1/14       1      eth  fabric up      none                        10G(D) 111
Eth1/15       1      eth  fabric up      none                        10G(D) 101
Eth1/16       1      eth  fabric up      none                        10G(D) 101
Eth1/17       1      eth  fabric up      none                        10G(D) 103
Eth1/18       1      eth  fabric up      none                        10G(D) 103
Eth1/19       1      eth  fabric up      none                        10G(D) 109
Eth1/20       1      eth  fabric up      none                        10G(D) 109

--------------------------------------------------------------------------------
Port-channel VLAN  Type Mode   Status  Reason                    Speed  Protocol
Interface                                                                
--------------------------------------------------------------------------------
Po11         1000  eth  trunk  up      none                       a-10G(D)  lacp
Po12         1000  eth  trunk  up      none                       a-10G(D)  lacp
Po64         1000  eth  trunk  up      none                       a-10G(D)  lacp
Po101        1     eth  fabric up      none                       a-10G(D)  none
Po103        1     eth  fabric up      none                       a-10G(D)  none
Po105        1     eth  fabric up      none                       a-10G(D)  none
Po107        1     eth  fabric up      none                       a-10G(D)  none
Po109        1     eth  fabric up      none                       a-10G(D)  none
Po111        1     eth  fabric up      none                       a-10G(D)  none
Po201        1000  eth  trunk  up      none                      a-1000(D)  none
Po202        1000  eth  trunk  up      none                      a-1000(D)  none

--------------------------------------------------------------------------------
Port   VRF          Status IP Address                              Speed    MTU
--------------------------------------------------------------------------------
mgmt0  --           up     192.168.104.14                          100      1500

-------------------------------------------------------------------------------
Interface Secondary VLAN(Type)                    Status Reason                 
-------------------------------------------------------------------------------
Vlan1     --                                      down   Administratively down   
Vlan1000  --                                      up     --        

--------------------------------------------------------------------------------
Ethernet      VLAN   Type Mode   Status  Reason                   Speed     Port
Interface                                                                   Ch #
--------------------------------------------------------------------------------
Eth101/1/1    10     eth  access down    Link not connected         auto(D) --
Eth101/1/2    10     eth  access up      none                       1000(D) --
Eth101/1/3    10     eth  access up      none                       1000(D) --
Eth101/1/4    71     eth  access up      none                       1000(D) --
Eth101/1/5    10     eth  access up      none                       1000(D) --
Eth101/1/6    71     eth  access up      none                       1000(D) --
Eth101/1/7    71     eth  access up      none                       1000(D) --
Eth101/1/8    10     eth  access down    Link not connected         auto(D) --
Eth101/1/9    20     eth  access down    Link not connected         auto(D) --
Eth101/1/10   20     eth  access down    Link not connected         auto(D) --
Eth101/1/11   71     eth  access down    Link not connected         auto(D) --
Eth101/1/12   1      eth  access down    Link not connected         auto(D) --
Eth101/1/13   60     eth  access up      none                       1000(D) --
Eth101/1/14   60     eth  access down    Link not connected         auto(D) --
Eth101/1/15   60     eth  access down    Link not connected         auto(D) --
Eth101/1/16   60     eth  access down    Link not connected         auto(D) --
Eth101/1/17   60     eth  access down    Link not connected         auto(D) --
Eth101/1/18   60     eth  access down    Link not connected         auto(D) --
Eth101/1/19   1      eth  access down    Link not connected         auto(D) --
Eth101/1/20   1      eth  access down    Link not connected         auto(D) --
Eth101/1/21   1      eth  access down    Link not connected         auto(D) --
Eth101/1/22   1      eth  access down    Link not connected         auto(D) --
Eth101/1/23   1      eth  access down    Link not connected         auto(D) --
Eth101/1/24   1      eth  access down    Link not connected         auto(D) --
Eth103/1/1    10     eth  access up      none                       1000(D) --
Eth103/1/2    10     eth  access up      none                       1000(D) --
Eth103/1/3    10     eth  access up      none                       1000(D) --
Eth103/1/4    20     eth  access up      none                       1000(D) --
Eth103/1/5    71     eth  access up      none                       1000(D) --
Eth103/1/6    120    eth  access up      none                       1000(D) --
Eth103/1/7    10     eth  access up      none                       1000(D) --
Eth103/1/8    10     eth  access down    Link not connected         auto(D) --
Eth103/1/9    10     eth  access down    Link not connected         auto(D) --
Eth103/1/10   10     eth  access down    Link not connected         auto(D) --
Eth103/1/11   1      eth  access down    Link not connected         auto(D) --
Eth103/1/12   1      eth  access down    Link not connected         auto(D) --
Eth103/1/13   60     eth  access up      none                       1000(D) --
Eth103/1/14   60     eth  access down    Link not connected         auto(D) --
Eth103/1/15   60     eth  access down    Link not connected         auto(D) --
Eth103/1/16   60     eth  access down    Link not connected         auto(D) --
Eth103/1/17   60     eth  access down    Link not connected         auto(D) --
Eth103/1/18   60     eth  access down    Link not connected         auto(D) --
Eth103/1/19   1      eth  access down    Link not connected         auto(D) --
Eth103/1/20   1      eth  access down    Link not connected         auto(D) --
Eth103/1/21   24     eth  access up      none                       1000(D) --
Eth103/1/22   1      eth  access down    Link not connected         auto(D) --
Eth103/1/23   1      eth  access down    Link not connected         auto(D) --
Eth103/1/24   1      eth  access down    Link not connected         auto(D) --
Eth105/1/1    10     eth  access up      none                       1000(D) --
Eth105/1/2    10     eth  access up      none                       1000(D) --
Eth105/1/3    10     eth  access up      none                       1000(D) --
Eth105/1/4    10     eth  access down    Link not connected         auto(D) --
Eth105/1/5    10     eth  access down    Link not connected         auto(D) --
Eth105/1/6    60     eth  access up      none                       1000(D) --
Eth105/1/7    10     eth  access down    Link not connected         auto(D) --
Eth105/1/8    10     eth  access down    Link not connected         auto(D) --
Eth105/1/9    10     eth  access up      none                       1000(D) --
Eth105/1/10   10     eth  access up      none                       1000(D) --
Eth105/1/11   1000   eth  trunk  up      none                       1000(D) 201
Eth105/1/12   1000   eth  trunk  up      none                       1000(D) 201
Eth105/1/13   60     eth  access down    Link not connected         auto(D) --
Eth105/1/14   60     eth  access up      none                       1000(D) --
Eth105/1/15   60     eth  access down    Link not connected         auto(D) --
Eth105/1/16   60     eth  access down    Link not connected         auto(D) --
Eth105/1/17   60     eth  access up      none                       1000(D) --
Eth105/1/18   60     eth  access up      none                       1000(D) --
Eth105/1/19   1      eth  access down    Link not connected         auto(D) --
Eth105/1/20   1      eth  access down    Link not connected         auto(D) --
Eth105/1/21   24     eth  access up      none                       1000(D) --
Eth105/1/22   24     eth  access up      none                       1000(D) --
Eth105/1/23   560    eth  access up      none                       1000(D) --
Eth105/1/24   560    eth  access up      none                       1000(D) --
Eth107/1/1    10     eth  access up      none                       1000(D) --
Eth107/1/2    10     eth  access up      none                       1000(D) --
Eth107/1/3    20     eth  access up      none                       1000(D) --
Eth107/1/4    10     eth  access down    Link not connected         auto(D) --
Eth107/1/5    10     eth  access down    Link not connected         auto(D) --
Eth107/1/6    60     eth  access up      none                       1000(D) --
Eth107/1/7    10     eth  access down    Link not connected         auto(D) --
Eth107/1/8    10     eth  access down    Link not connected         auto(D) --
Eth107/1/9    10     eth  access up      none                       1000(D) --
Eth107/1/10   10     eth  access down    Link not connected         auto(D) --
Eth107/1/11   1000   eth  trunk  up      none                       1000(D) 202
Eth107/1/12   1000   eth  trunk  up      none                       1000(D) 202
Eth107/1/13   60     eth  access down    Link not connected         auto(D) --
Eth107/1/14   60     eth  access down    Link not connected         auto(D) --
Eth107/1/15   60     eth  access down    Link not connected         auto(D) --
Eth107/1/16   60     eth  access down    Link not connected         auto(D) --
Eth107/1/17   60     eth  access up      none                       1000(D) --
Eth107/1/18   60     eth  access up      none                       1000(D) --
Eth107/1/19   24     eth  access down    Link not connected         auto(D) --
Eth107/1/20   24     eth  access down    Link not connected         auto(D) --
Eth107/1/21   24     eth  access up      none                       1000(D) --
Eth107/1/22   24     eth  access up      none                       1000(D) --
Eth107/1/23   560    eth  access up      none                       1000(D) --
Eth107/1/24   560    eth  access up      none                       1000(D) --
Eth109/1/1    10     eth  access up      none                       1000(D) --
Eth109/1/2    10     eth  access up      none                       1000(D) --
Eth109/1/3    10     eth  access up      none                       1000(D) --
Eth109/1/4    10     eth  access up      none                       1000(D) --
Eth109/1/5    10     eth  access up      none                       1000(D) --
Eth109/1/6    10     eth  access up      none                       1000(D) --
Eth109/1/7    20     eth  access up      none                       1000(D) --
Eth109/1/8    10     eth  access down    Link not connected         auto(D) --
Eth109/1/9    10     eth  access up      none                       1000(D) --
Eth109/1/10   10     eth  access up      none                       1000(D) --
Eth109/1/11   1000   eth  access up      none                       1000(D) --
Eth109/1/12   1      eth  access down    Link not connected         auto(D) --
Eth109/1/13   60     eth  access up      none                       1000(D) --
Eth109/1/14   60     eth  access up      none                       1000(D) --
Eth109/1/15   60     eth  access down    Link not connected         auto(D) --
Eth109/1/16   60     eth  access down    Link not connected         auto(D) --
Eth109/1/17   60     eth  access up      none                       1000(D) --
Eth109/1/18   60     eth  access up      none                       1000(D) --
Eth109/1/19   1      eth  access down    Link not connected         auto(D) --
Eth109/1/20   1      eth  access down    Link not connected         auto(D) --
Eth109/1/21   24     eth  access up      none                       1000(D) --
Eth109/1/22   24     eth  access up      none                       1000(D) --
Eth109/1/23   560    eth  access up      none                       1000(D) --
Eth109/1/24   560    eth  access up      none                       1000(D) --
Eth111/1/1    10     eth  access up      none                        100(D) --
Eth111/1/2    10     eth  access up      none                        100(D) --
Eth111/1/3    10     eth  access up      none                        100(D) --
Eth111/1/4    10     eth  access up      none                       1000(D) --
Eth111/1/5    10     eth  access up      none                        100(D) --
Eth111/1/6    10     eth  access up      none                        100(D) --
Eth111/1/7    10     eth  access up      none                        100(D) --
Eth111/1/8    10     eth  access up      none                        100(D) --
Eth111/1/9    10     eth  access up      none                       1000(D) --
Eth111/1/10   10     eth  access down    Link not connected         auto(D) --
Eth111/1/11   1      eth  access down    Link not connected         auto(D) --
Eth111/1/12   1      eth  access down    Link not connected         auto(D) --
Eth111/1/13   60     eth  access up      none                       1000(D) --
Eth111/1/14   60     eth  access up      none                       1000(D) --
Eth111/1/15   60     eth  access down    Link not connected         auto(D) --
Eth111/1/16   20     eth  access up      none                       1000(D) --
Eth111/1/17   60     eth  access down    Link not connected         auto(D) --
Eth111/1/18   60     eth  access down    Link not connected         auto(D) --
Eth111/1/19   24     eth  access up      none                       1000(D) --
Eth111/1/20   24     eth  access up      none                       1000(D) --
Eth111/1/21   24     eth  access up      none                       1000(D) --
Eth111/1/22   1      eth  access down    Link not connected         auto(D) --
Eth111/1/23   1      eth  access down    Link not connected         auto(D) --
Eth111/1/24   1      eth  access down    Link not connected         auto(D) --

You, Me and NAT 8.3

Leave a reply

NAT on ASA 8.3 and higher

It is important to know that the change from 8.2 to 8.3 was massive. It did divide ASA users to a point some felt cheated or disheartened by Cisco’s actions. I admittedly picked it up rather quickly though others who are been using the family for years had a tougher time. The biggest change comes in the syntax. ASA 8.3 and higher leverages the use of object-orientated configuration which allowed the overcoming of 8.2 caveats. The biggest bonus is the ability to scale firewall rule bases. Other features such as the keyword any, defining translations as objects, and ACL, MPF, AAA features matching the real/un-translated address.

Order of Operations – 8.3 and higher ASA

Manual NAT
Auto NAT
Manual NAT after Auto

It is important to understand that NAT translations are now treated much like an access-list. It is best to place the most specific rules at the top and lease specific towards the bottom.

Configuring Auto NAT – 8.3 ASA

This new version of NAT is easiest to configure. It also goes by the name of Object NAT. There are three types of auto NAT configurations.

Static NAT – one to one translation for static hosts. Adds in a permanent connection entry.
Dynamic NAT – allows multiple uses of single pool of addresses. PAT is used when address pool is full.
Dynamic PAT – allows multiple addresses to use one or more translated addresses simultaneously.

Auto NAT – Static NAT – 8.3 ASA

The configuration of Static NAT in the 8.3 software is very different but very scalable.

object network internal-mail
host 192.168.16.23
object network internal-mail-outside
host 203.66.23.84
object network internal-mail
nat (inside,any) static internal-mail-outside

Here we define two objects. internal-mail and internal-mail-outside with their respective IP addresses. We then define under internal-mail the NAT we want to take place. The ASDM configuration window resides at Configuration > Firewall > Objects > Network Objects/Groups.

Auto NAT – Dynamic NAT – 8.3 ASA

Dynamic Translations of NAT in 8.3 again utilize objects. A subnet is defined here opposed to a 1:1 mapping of addresses like static NAT.

object network 172.16.23.0_NET
subnet 172.16.23.0 255.255.255.0
nat (inside,outside) dynamic interface

The object we define in this part is actually an entire subnet. We are allowing the subnet 172.16.23.0/24 to be natted to the IP address of the outside interface. This type of NAT is generally what is applied to an end-user subnet. The ASDM configuration window resides at Configuration > Firewall > Objects > Network Objects. Select Network Object from the dropdown. When filling out the information it is important to tick Add Automatic Address Translation Rules.

Manual NAT – 8.3 ASA

Manual NAT takes precedence over auto NAT in the translation table. Manual NAT can also be configured to be processed after auto NAT. This allows for a fall back scenario and deterministic failover. It can be configured on both source and destination IP addresses; this is known as Twice NAT.

object network 10.10.1.0_NET
subnet 10.10.1.0 255.255.255.0
object network 65.242.123.97_outside
host 65.242.123.97
object network 184.63.22.23_MAIL
host 184.63.22.23
nat (inside,outside) source dynamic 10.10.1.0_NET 65.242.123.97_outside destination static 184.63.22.23_MAIL 184.63.22.23_MAIL

So what is happening here? First we begin by translating packets from the inside to outside with (inside,outside). Source dynamic translate the source IP with dynamic translation. 10.10.1.0_NET 65.242.123.97_outside will translate source IP packets defined in the object 10.10.1.0_NET to global addresses defined by the object 65.242.123.97_outside. Destination static defines destination IP translation as static and the object 184.63.22.23_MAIL is the destination IP that is set to not be translated.

The ASDM configuration window resides at Configuration > Firewall > NAT Rules > and select the Add NAT Rule Before “Network Object” NAT dropdown.

Twice NAT – Source and Destination NAT

There are occasions where RFC 1918 addresses overlap. When they do Twice NAT has its place. Lower ranges in this address space are commonly used by all kinds of networks; Twice NAT can be configured to avoid this.

object network INSIDE-CUSTA-NET
subnet 192.168.1.0 255.255.255.0
object network 192.168.10.11_PAT
host  192.168.10.11
object network 192.168.10.0_NET
network 192.168.10.0 255.255.255.0
object network 192.168.11.0_NET
network 192.168.11.0 255.255.255.0
nat (inside,CUST_A) source dynamic INSIDE-CUSTA-NET 192.168.10.11_PAT destination static 192.168.1.0_NET 192.168.11.0_NET

After defining our objects we then apply the NAT statement. The traffic that now flows from the interface inside to CUST_A is now subject to translation rules. The dynamic source of the translation is the object network INSIDE-CUSTA-NET to network defined by 192.168.10.11_PAT. Destination static will translate the destination IP address using static translations. 192.168.1.0_NET 192.168.11.0_NET will translate addresses that are defined by 192.168.11.0_NET to addresses defined by 192.168.1.0_NET.

The ASDM configuration window resides at Configuration > Firewall > NAT Rules > and select the Add NAT Rule Before “Network Object” NAT dropdown.

Manual NAT after Auto NAT – 8.3 ASA

This type of NAT allows for translations after not meeting the criteria of more specific matches.

nat (any,outside) after-auto 1 source dynamic 192.168.16.0_NET 203.86.14.0_NET_OUT

The biggest difference in this command is the after-auto. This is what sets it to translate after auto NAT has been processed. The ASDM configuration window resides at Configuration > Firewall > NAT Rules > and select the Add NAT Rule After “Network Object” NAT dropdown.

Directional NAT

Directional NAT translations are based upon the direction of the request. If the source object that is defined makes a request it is only translated once. By default a NAT translation occurs both ways.

nat (inside,dmz14) source static MAIL-14-INT MAIL-14-EXT unidirectional

The keyword unidirectional is what allows this function to take place. The ASDM configuration window resides at Configuration > Firewall > NAT Rules > Edit NAT Rule.

NAT Caveats

It is important to know where NAT can be used and where NAT will cause headaches. The list below is situations where NAT will cause you to have a bad day.

Embedded IP addressing
End-to-end encryption
Authenticated IP packets
- IP headers
- TCP headers
- IPSEC
8.2 ASA NAT changes configuration of ACL, AAA, MPF due to the fact 8.2 references the post-NAT IP.

NATing like it’s Nineteen Ninety Nine

Leave a reply

–Network Address Translation, ASA 8.2

NAT is required for a number of scenarios and can be used in the most unusual places. Most common is translation of a private RFC 1918 address into a globally routed public IP address. An example of this would be a home device with an address of 10.10.16.10 being translated to 200.165.231.20 when going to the internet. The translation table keeps a record of this conversation and then when the destination packet returns to 200.165.231.20 it is sent back to the device it originated from – 10.10.16.10. There are a number of different NAT styles and syntax styles. Syntax changes between 8.2 and 8.3 caused commotion among ASA users. This section will clearly state which NAT method is being used.

Order of Operations – 8.2 ASA

The interface order of operations is important to understand where NAT takes its place in connection criteria.

NAT Exemption
Static NAT and Static PAT
Policy Dynamic NAT
Regular Dynamic NAT
NAT Control on and no match will drop packet

Dynamic NAT – 8.2 ASA

Dynamic NAT will translate an IP address into a pre-defined pool of addresses for communication. Generally this is employed in a situation of higher security to lower security. An address is generally reserved for PAT in case the pool defined fills.

nat (inside) 1 10.10.10.0 255.255.255.0

global (outside) 1 192.168.20.15-192.168.20.150

global (outside) 1 192.168.20.151

The above example of 8.2 Dynamic NAT will take addresses from the inside source range of 10.10.10.0/24 and translate them to an address on 192.168.20.15-150 range. This occurs when traffic goes from inside to outside. If the translation pool fills the 192.168.20.151 address is there to perform PAT.

The ASDM configuration window resides at Configuration > Firewall > NAT Rules. Then select Add Dynamic NAT Rule.

Static NAT – 8.2 ASA

Static NAT’s recommended use is where an application based server needs to be accessed from an external network. Due to a translation is always present in the table, remote connections can establish. It is best used when connections need to be established from an outside interface which has a lower-security level than the host being accessed. The addresses listed are what we will use for our example. The server has an internal address of 192.168.16.10 on interface dmz-mail and outside requests hit 202.16.142.30 on interface isp-a.

static (dmz-mail,isp-a) 202.16.142.30 192.168.16.10

A good way to remember static 8.2 NAT is the following structure defined in the table below.

Real IP	Mapped IP	Mapped IP	Real IP
dmz-mail	isp-a	isp-a	dmz-mail

The ASDM configuration window resides at Configuration > Firewall > NAT Rules. Then select Add Static NAT Rule.

Static Exemption, Exemption and Identity NAT – 8.2 ASA

The following examples are devices that do not need NAT translations to take place.

Static identity NAT creates a slot in the translation table as it is configured.

static (dmz-c,outside) 206.100.100.42 206.100.100.42 netmask 255.255.255.255

Dynamic identity NAT will create a dynamic identity in the translation table. This is where the local and global addresses are the same. Used when clients access less secure interfaces.

nat (inside) 0 10.36.100.0 255.255.255.0

Remember that a pool ID of 0 is a specific command to the ASA software not to translate.

Finally is NAT exemption. This mode behaves differently due to the fact it bypasses NAT operations in the Order of Operations.

nat (inside) 0 access-list CI-VPN

The ASDM configuration window resides at Configuration > Firewall > NAT Rules. Then select Add Static NAT Rule. Ensure NAT Exempt Outbound Traffic from Interface “inside” to Lower Security Interfaces (Default) is enabled for Exemption.

NAT caveats for 8.2

NAT control was a feature of 8.2. It ensured that NAT rules had to be in place when enabled; Traffic would be dropped if no translation rule was found. NAT exemption was the other way for traffic to traverse a firewall when NAT control was enabled. This did lead to excess configuration on the firewalls. In ASA 8.3 this feature was removed completely. If a connection cannot find a translation it is allowed and is subject to other access policies.