by Tony Mattke on April 24, 2012
INE published a great info-graphic on the earning potential of Cisco’s certifications and I felt the need to share it here. It covers a range of topics from average salaries on all three tiers of proficiency, to top locations for positions, always remember that the information included is in no way meant as career advice.

by Tony Mattke on April 19, 2012
In situations where service providers want to offer transparent LAN services that preserve a customers VLAN tags across your Layer-2 network, This amendment to the IEEE 802.1q standard allows us to use a single VLAN to transport multiple VLANS across the MAN or WAN. In doing so, we stack on an extra 802.1q tag to the customer’s traffic at the provider’s edge (PE). The original 802.1Q specification allows a single VLAN header to be inserted into an Ethernet frame. QinQ allows multiple VLAN headers to be inserted into a single frame, this is essential when implementing Metro Ethernet networks.
QinQ Configuration
First we need to ensure our transport switches can support the baby giant frames. To check the current MTU on the switch you can issue the command show system mtu and in global configuration mode, you can use system mtu 1504 to change the switches MTU to the recommended 1504 bytes..
SW1# show system mtu
System MTU size is 1500 bytes
SW1# configure terminal
SW1(config)# system mtu 1504
Changes to the System MTU will not take effect until the next reload is done.
The actual QinQ configuration takes place entirely on the transport switches, no modifications are required on the customer equipment. The first step is to configure the trunk between our two backbone switches. We’ll be using VLAN 101 for Customer-A, and 201 for Customer-B. As you will see, the configuration is rather quick and simple.
SW1(config)# interface fa1/0/48
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 101,201
SW2(config)# interface fa1/0/48
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 101,201
[ read more... ]
by Tony Mattke on March 30, 2012
Since I’ve recently had some fun working with the Cisco 5585-X and the IPS blades, I wanted to document some of the information I learned while getting them online. Some of this came from various sources around the ‘net including the TAC IPS group, other parts are from consultants, or what we just figured out on our own while working with it. The first thing you need to understand is how traffic gets to / from the IPS. The easiest way to explain it, is that the IPS sits inside the firewall. It will be sent traffic, from a matched ACL, after the interface has performed it’s own inbound ACL filtering. In our situation, we simply defined an ACL that stated permit ip any any — but depending on the application, you may only want to filter traffic in certain directions. Below, we have an example that filters traffic with a destination defined in our object-group. The ACL you defined is matched in a class-map, which is matched in your global_policy policy-map. The command ips inline fail-open sensor vs0 actually sends the traffic (via the backplane) to the IPS blade. This command also states, that if the ASA detects an issue with the IPS, to bypass it, and continue to pass traffic as if it was never installed. To cease the flow of traffic to the sensor, remove this command from the policy-map… This would be rather usefull if a bad set of signatures were deployed and the IPS was erroneously dropping traffic.
object-group network IPS-RANGES
network-object 10.0.0.0 255.0.0.0
network-object 4.2.2.0 255.255.255.0
!
access-list IPS-ACL permit ip any object-group IPS-RANGES
!
class-map IPS-CLASSMAP
match access-list IPS-ACL
!
policy-map global_policy
class IPS-CLASSMAP
ips inline fail-open sensor vs0
[ read more... ]
by Tony Mattke on March 28, 2012
As a follow up to my blog post on the PacketPushers blog, I wanted to share with you another time saving tip for getting our jobs done not only quickly, but helping to remove one of the tedious steps in firewall maintenance. Today, I needed to add a large chunk of ACEs to my INSIDE-IN ACL (about 6 times larger than my example here, but spread across a couple devices..) Luckily, I used my head when it came time to start adjusting line numbers. The first thing I did was to write out my ACEs, and instead of filling in the line numbers, I just used XXX. (I would be deploying this in a few places, so I saved a couple versions as well..)
Sample output included below: IP Addresses were changed to protect the innocent…
[ read more... ]
by Tony Mattke on December 23, 2011

Recently I’ve been lucky enough to be challenged with learning a bit about Fibre Channel Switching, but I’m even luckier in that I’m getting to know it on a set of MDS switches running NX-OS (previously referred to as SAN-OS). So far, I’ve learned the basics of getting things to work, but nothing really beyond that. As the SAN world has always been a mystery to me, I figured I would share what I’ve learned with other engineers that are at least looking for a baseline look into the storage network.
New Terminology
First, lets familureize ourselves with a few terms that we may run into when dealing with the very basics of FC switching…
- WWN: World Wide Name, think 8-byte MAC address. Also pWWN/sWWN (Port/Switch WWN) — This is the addressing of the Fibre Channel world. All of our configs are going to use pWWNs (Port World Wide Names, which actually refer to the node, or N_port)
- vSAN: A vSAN is a virtual collection of ports, sort of like a VRF, or even a vDC (but within the same management plane) — Each port can only be a member of one vSANs. — From my understanding, This is a Cisco specific technology typically used to create at least one unique vSAN per switch. This defines the two (or more) distinct fabric paths.
- Zone: a Zone is a grouping of ports inside a vSAN used to control which devices can speak with other devices. Devices can be members of multiple zones. Devices in different Zones cannot speak to each other. — Think VLAN.
- N_port: Node Port — Could be a Host, or Storage device.
- F_port: Fabric port — Connects to an N_port
- FLOGI: Fibre Channel Logins — Used to exchange device information. Including WWNs
[ read more... ]
by Tony Mattke on November 16, 2011
Our second visit on day 2 of Network Field day was Brocade, who incidentally supplied us with a great lunch! We spent a little time going through the expected marketing presentation, fortunately they kept it short and to the point… Next up was another short presentation from Jon Hudson, aka @the_socialist, who started things out with a overview of Brocade and their core product line. Fortunately for us, Jon had done his homework and cropped his presentation down to the essentials which aided in keeping our short attention-span on focus. All of this lead up to the surprise they had waiting for us. A live Brocade VCS lab. Yes, you read that correctly. A full, hands on lab. Not a demo, not a video.
[ read more... ]
by Tony Mattke on November 4, 2011

The second day of Network Field Day 2 started early at the Juniper EBC, luckily Abner Germanow was prepared with breakfast for the weary and slightly hung over delegates. He gave us an overview of Juniper Networks as a whole including some back history of how they started innovating by putting routing code into ASICs. He quickly handed of to Dan Backman who started off by talking about how Junos has developed itself around workflows. He demonstrated the extensibility of Junos through tools like XML and API calls. Because of the way it was developed, they have the unique ability to provide powerful scripting and automation tools. Dan actually told us that the entire Junos back end is XML, which is VERY interesting. Next he brought up a live Juniper lab to show us the real power of their scripting/automation. This is the first time I’ve heard of Junos commit scripts, which I now wish I had in IOS. During this entire demonstration all of delegates really seemed to enjoy the flexibility Dan was demonstrating, by the end, he had us all drooling over it. And that was before he dropped the bombshell… his entire demonstration had been running inside of Junosphere. Before we were able to bombard him with questions about how to get access to it, he showed some a rather impressive demo using Cariden Mate, and an IS-IS db gathered from what appears to be the I2 backbone. Very cool stuff. Cariden was able to generate a topology from the database, and their plugin for Cariden was able to generate the appropriate Junosphere configuration/startup files. Several times during his presentation he made reference to there being “one more thing” or some secret he wanted to share. It wasn’t long before we learned they were going to give us access to Junosphere for testing! Be on the lookout for my Junosphere review once I’m able to check it out.
[ read more... ]
by Tony Mattke on November 3, 2011

I could’ve just as easily called this article Gigamon… fixing problems you didn’t know about or Why Gigamon scares the crap out of me — but I wont, because they already did! But what I will say, is that Gigamon has become a very interesting product to me…
Gigamon’s product line-up mainly consists of optical fiber and electrical copper taps for network connections, and a series of aggregation taps with the capability to filter traffic being tapped and aggregated. Now, why do I find this interesting? Well, it all goes hand in hand with why your enterprise or ISP may be interested in their products…
[ read more... ]
Recent Comments